cvs commit: src/sys/kern subr_param.c sys_pipe.c src/sys/sys pipe.h

[Mike Silbersack]

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