PERFORCE change 188239 for review

[Edward Tomasz Napierala]

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

Change 188239 by trasz at trasz_victim on 2011/01/27 20:04:15

	Update TODO.

Affected files ...

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

Differences ...

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

@@ -1,6 +1,8 @@
 TODO:
 
- - Fix %CPU limits for shortly living processes.
+ - RCTL accesses resource usage information without holding container_lock.
+
+ - Fix cpu throttling.
 
  - Consider replacing proc pointer with thread pointer in rusage_add(9) et al.
    In most cases caller uses 'td->td_proc' anyway, and passing thread would
@@ -12,7 +14,8 @@
  - Get rid of container_lock.  Atomic instructions would be nice, but we really
    need 64 bits (per-process counters could be 32 bit, I guess, but the higher
    level containers could overflow), and atomic(9) doesn't support 64 bit values
-   on 32 bit platforms.
+   on 32 bit platforms.  Code ported from SunOS seems to use (and implement)
+   64 bit atomics.
 
  - Don't account resources for system processes.  It's not as easy as checking
    for P_SYSTEM flag, as the flag will be set for AIO kernel processes.
@@ -23,6 +26,11 @@
  - The jailstat(1)/userstat(1) tool seems to use lots of CPU time.  Rewriting
    it in C could make sense.
 
+ - Currently limit enforcement involves walking over the list of rules applicable
+   to the process.  I expect the number of such rules to be small (about five),
+   but some optimisation could be in order.  Maybe a list of pointers to rules,
+   one entry per resource?
+
 Issues:
 
  - Setting RSS limit too low can make the system thrash to death.
@@ -68,7 +76,7 @@
 
  - What about RLIMIT_RTPRIO and RLIMIT_RTTIME?  Linux seems to have these.
 
-HRL-specific issues:
+RCTL-specific issues:
 
  - Reconsider bringing back setrlimit(2) handling.