Date: Tue, 8 Jul 2003 00:57:40 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Don Lewis <truckman@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_param.c sys_pipe.c src/sys/sys pipe.h Message-ID: <20030708004340.T6733@odysseus.silby.com> In-Reply-To: <20030708000257.D6158@odysseus.silby.com> References: <200307080457.h684vRM7009343@gw.catspoiler.org> <20030708000257.D6158@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Jul 2003, Mike Silbersack wrote: > If I spend more time working on pipes, there are a bunch of other changes > I'll be working on first. > > Mike "Silby" Silbersack Let me explain this statement a little better, as it helps explain why I didn't do per-user limits in the initial commit. As pipes are implemented now (which basically still follows John's original design), for each side of a pipe we allocate: 1 VM object which is linked to 16KB of address space from the kernel map; this is pageable, and acquires backing as it is filled. For large writes which align on page boundaries, the pages are wired into kernel memory, and shown directly to the reading end of the pipe. Naturally, this memory isn't pageable, and is even more important to limit. (However, as stated in my commit message, this _can_ be limited without any nasty sideeffects.) As a result of all this memory usage (which is optimized for performance), and the small size of the kernel map (which I don't think we can expand too much on i386 without running out of KVA), the limit on pipes is far less than our limit on sockets or files. So, there are a few things that could be done to improve our memory usage, thereby allowing the quantity of pipes to grow substantially. 1. Reduce the number of vm objects required, perhaps down to 1. This should reduce the pressure on the vm system. (May be incompatible with how page flipping is done, however.) 2. Reduce the # of actual pages + address space used by pipe writes. It might not be a bad idea to start all pipes as 4K and size and have them grow as larger writes are handed to them. Additionally, the code could be made more aggressive in freeing pages after the read is complete. #1 & #2 would probably best be accomplished by moving pipe storage into a UMA zone once Jeff has the support for pageable backing done. :) 3. Perhaps the page flipping case can be improved so that it does not require wiring the pages in question into the kernel, thereby reducing memory pressure. But anyway, that's just theory, I don't think I'll end up doing any of that. However, if someone is looking for something to do, that might be an interesting project. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030708004340.T6733>