Subject: Re: Faster pipes from FreeBSD
To: Ross Harvey <ross@ghs.com>
From: Jaromír <jdolecek@netbsd.org>
List: tech-kern
Date: 04/06/2001 22:10:17
Ross Harvey wrote:
> I would suggest the following, perhaps obvious, cautions.
> 
>      o 	It really should have its own SMP-safe lock calls, but it
>		doesn't.

lockmgr(9), or would just spinlocks do ?

>      o	Finish UVM integration

Yep. First of all, use a separate uvm_object instead of mapping the pipe
buffer off kernel_map, probably :)
 
>      o	Things like, e.g.,  LIMITBIGPIPES should be done another way,
> 	at a minimum it should be:
> 		int limitbigpipes = LIMITBIGPIPES;

IMHO sysctl(8) should do. I agree the number should be adjusted on
boot according to available memory (some init routine needs to be
added anyway, currently the pipe_zone pool is initialized on first
sys_pipe(2) call, which is ... suboptimal).

> I think the above stuff should be done before commit, not after.

Don't know; I'm considering a little branch, so that the code is
more easily available to people (and under CVS control).

> I have at least one concern about the wisdom of this entire approach.
> 
>     o   Because this hooks into the system at the kernel descriptor level,
> 	i.e., the outermost possible layer, it needs to implement every
> 	little semantic someone might expect of pipes, as well as do

There is little one is allowed to expect from pipes according to
POSIX. Traditionally, we were using socketpair(), so support for
some socket ioctls should be retained. Not much more, IMHO. As a
matter of fact, our pipes even didn't follow SysV semantics - they
were unidirectional, but SVR4 pipes are birectional IIRC.

> 	its own SMP locks, as it adds an entire third I/O type to the
> 	previous choice of merely: vnode or socket.

I think it makes sense to do this for the very special beings pipes
are. Pipes are the very  centre of unix model and it's definitely worth it
to make them as efficient as possible, IMHO. Even through it's
good to have generic interfaces, the layering might add too
much burden with little to no gain in this case.
 
Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=<>=- Got spare MCA cards or docs? Hand me them!