Date: Thu, 26 Aug 2010 20:35:55 GMT From: Edward Tomasz Napierala <trasz@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 182939 for review Message-ID: <201008262035.o7QKZtjV065815@skunkworks.freebsd.org>
index | next in thread | raw e-mail
http://p4web.freebsd.org/@@182939?ac=10 Change 182939 by trasz@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.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008262035.o7QKZtjV065815>