Date: Thu, 10 Jul 2003 14:19:21 -0500 From: "Alan L. Cox" <alc@imimic.com> To: David Schultz <das@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: <3F0DBC39.891A91A@imimic.com> References: <200307080457.h684vRM7009343@gw.catspoiler.org> <20030708000257.D6158@odysseus.silby.com> <20030708004340.T6733@odysseus.silby.com> <3F0B199E.A3C980D2@imimic.com> <20030710182436.GA6484@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote: > > On Tue, Jul 08, 2003, Alan L. Cox wrote: > > Mike Silbersack wrote: > > > > > > 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.) > > > > When "pages are wired into kernel memory" there are two distinct actions > > being performed: vm_page_wire() and pmap_qenter(). However, as far as I > > know, there is no reason why the pmap_qenter() has to be performed by > > the sender. I suspect the mapping could be delayed until just before > > the copy and released immediately thereafter, thereby eliminating the > > need for each pipe to have its own KVA for this purpose. In fact, I > > believe the sf_buf allocator could be used to provide the temporary KVA. > > That would alleviate the KVA pressure, since the mapping would be > very temporary and you could even get away with just a single > page. However, it would still tie up the associated physical > memory until the pipe is read, which may not be soon at all. Is > there a reason for the memory to be wired, other than that the > data is easier to track down while the sending process' PTEs are > still there? I would expect that you could instead just look up > the appropriate vm_object and lazily fault in the appropriate pages > on the receiver's side, modulo a few details such as segfault handling. > But perhaps I'm missing something... It's a matter of priorities. With the growth trend in physical memory sizes (and PAE), I see more problems due to KVA pressure than unnecessarily wired memory. A recent, and fairly visible example, was the vnode autosizing problems that had to be fixed prior to 5.1-RELEASE. Regards, Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F0DBC39.891A91A>