PERFORCE change 182939 for review

[Edward Tomasz Napierala]

http://p4web.freebsd.org/@@182939?ac=10

Change 182939 by trasz at trasz_victim on 2010/08/26 20:35:14

	Update TODO.

Affected files ...

.. //depot/projects/soc2009/trasz_limits/TODO#27 edit

Differences ...

==== //depot/projects/soc2009/trasz_limits/TODO#27 (text+ko) ====

@@ -9,15 +9,12 @@
  - locked memory usage (RUSAGE_MEMLOCK), in megabytes
  - resident set size (physical memory usage) (RUSAGE_RSS), in megabytes
  - stack size (RUSAGE_STACK), in megabytes,
+ - number of file descriptors (RUSAGE_NOFILE)
+ - swap usage (RUSAGE_SWAP), in megabytes
+ - amount of memory consumed by socket buffers (RUSAGE_SBSIZE), in megabytes
 
 Limits to do:
 
-Milestone 1:
-
- - swap usage (RUSAGE_SWAP), in megabytes
- - number of file descriptors (RUSAGE_NOFILE)
- - amount of memory consumed by socket buffers (RUSAGE_SBSIZE), in megabytes
-
 Milestone 2:
 
  - number of kernel-visible threads (RUSAGE_NTHR)
@@ -68,6 +65,22 @@
    Also, try to figure out what's going on with 'intr' p_flag - checking for P_SYSTEM
    didn't really work for that process.
 
+ - Right now, the whole containers stuff is under a single mutex.  This is internal
+   to containers, i.e. the API consumers don't need to care, thus it's easy to change.
+
+   I'd need to run benchmarks first, but two strategies come to mind:
+
+   1. Replace container_lock with rmlock, protecting the container hierarchy.  The lock
+      would be acquired for write in operations changing the hierarchy, and for read
+      for all other operations.  When locked for read, the counters would be accessed
+      using atomic instructions.
+
+   2. Replace single container_lock with individual per-container mutexes.
+
+ - RUSAGE_NOFILE accounts for size of file descriptor table, rather than the number
+   of file descriptors.  This shouldn't be a problem, but might be worth remembering
+   about.
+
 HRL-specific issues:
 
  - Bring back per-group limits.