Date: Thu, 10 Jul 2003 17:22:48 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: David Schultz <das@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_param.c sys_pipe.c src/sys/sys pipe.h Message-ID: <20030710171542.E1451@odysseus.silby.com> In-Reply-To: <20030710182436.GA6484@HAL9000.homeunix.com> References: <200307080457.h684vRM7009343@gw.catspoiler.org> <20030708004340.T6733@odysseus.silby.com> <20030710182436.GA6484@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jul 2003, David Schultz wrote: > 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... I had thought the same thing, but then I realized that the wiring isn't a big deal: In the "normal" case, the pipe data would be stored in pageable kernel memory. In the "fast" case, we wire the pipe data down, but don't use any additional memory. Hence, we're not _really_ wasting any physical memory in the fast case; the only point where that wired memory would matter is if the machine was swapping like mad, but since we now have a limit on the amount of memory that can be wired, that won't be a significant problem. As a result, I've come to the conclusion that wiring the memory, but delaying the pmap_qenter until we actually do the copy is about all we need to do to improve this case. I have another improvement in the pipeline that will actually have more of an impact; right now, we alllocate a VM object + backing store for both directions of the pipe. However, most programs only use one direction of the pipe (AFAIK.) So, I'm going to delay the allocation of the vm object + backing store until an actual write occurs so that we only allocate for space that we will use. This should cut the amount of address space used in half, assuming that most users are unidirectional. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030710171542.E1451>