Date: Fri, 21 Jan 2011 16:53:53 GMT From: Edward Tomasz Napierala <trasz@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 188035 for review Message-ID: <201101211653.p0LGrrLC081131@skunkworks.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://p4web.freebsd.org/@@188035?ac=10 Change 188035 by trasz@trasz_victim on 2011/01/21 16:53:15 Update TODO, expand manual page. Affected files ... .. //depot/projects/soc2009/trasz_limits/TODO#40 edit .. //depot/projects/soc2009/trasz_limits/usr.bin/rctl/rctl.8#3 edit Differences ... ==== //depot/projects/soc2009/trasz_limits/TODO#40 (text+ko) ==== @@ -1,44 +1,29 @@ -Limits done: +TODO: - - CPU time (RUSAGE_CPU), in microseconds - - data size (RUSAGE_DATA), in megabytes - - maximum file size (RUSAGE_FSIZE), in megabytes - - number of processes (RUSAGE_NPROC) - - virtual memory usage (address space limit) (RUSAGE_VMEM), in megabytes - - maximum core size (RUSAGE_CORE), in megabytes (core, as in ELF program state dump) - - 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 - - number of kernel-visible threads (RUSAGE_NTHR) - - wallclock time (RUSAGE_WALLCLOCK) - - %cpu time (RUSAGE_PCTCPU) - - number of SysV shared memory segments (RUSAGE_NSHM) - - SysV shared memory size, in megabytes (RUSAGE_SHMSIZE) - - number of SysV semaphores modified in a single semop(2) call (RUSAGE_NSEMOP) - - number of SysV semaphores (RUSAGE_NSEM) - - number of SysV queues (RUSAGE_NMSGQ) - - number of queued SysV messages (RUSAGE_MSGQQUEUED) - - SysV message queue size, in megabytes (RUSAGE_MSGQSIZE) + - Fix %CPU limits for shortly living processes. -Milestone 3: + - 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 + allow the HRL code to send a signal to the offending thread instead of the + offending process. It would also mean that these the functions would + no longer need to be called with proc lock held, because we could use + td->td_ucred, which is stable across the syscall. - - Fix %CPU limits for shortly living processes. - - 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. - - 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 - allow the HRL code to send a signal to the offending thread instead of the - offending process. + - 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. + + Also, try to figure out what's going on with 'intr' p_flag - checking for P_SYSTEM + didn't really work for that process. Issues: + - Setting RSS limit too low can make the system thrash to death. + - We enforce limits when a process allocates a resource, and when it forks. We don't enforce limits when process changes its credentials, though. This might be either a bug or feature, depending on point of view. @@ -66,24 +51,6 @@ container mechanism. This is a part of HRL, and it's outside the scope of the containers project. This means the code is full of "#ifdef CONTAINERS". - - 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. - - 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 keeping in mind. ==== //depot/projects/soc2009/trasz_limits/usr.bin/rctl/rctl.8#3 (text+ko) ==== @@ -116,6 +116,34 @@ or, in short, ":". A filter that matches all the login classes would be "loginclass:". A filter that matches all defined limits for maxprocesses resource would be "::maxprocesses". +.Pp +.Sh RESOURCES +.Bl -column -offset 3n "msgqqueued" +.It cpu CPU time, in microseconds +.It fsize maximum file size, in megabytes +.It data data size, in megabytes +.It stack stack size, in megabytes +.It core core dump size, in megabytes +.It rss resident set size, in megabytes +.It memlock locked memory, in megabytes +.It nproc number of processes +.It nofile file descriptor table size +.It sbsize memory consumed by socket buffers, in megabytes +.It vmem address space limit, in megabytes +.It npts number of PTYs +.It swap swap usage, in megabytes +.It nthr number of threads +.It msgqqueued number of queued SysV messages +.It msgqsize SysV message queue size, in megabytes +.It nmsgq number of SysV message queues +.It nsem number of SysV semaphores +.It nsemop number of SysV semaphores modified in a single semop(2) call +.It nshm number of SysV shared memory segments +.It shmsize SysV shared memory size, in megabytes +.It wallclock wallclock time +.It pctcpu %cpu time +.El +.Pp .Sh EXIT STATUS .Ex -std .Sh SEE ALSO
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101211653.p0LGrrLC081131>