Subject: Re: Not beer, or why is the pipe so small?
To: None <>
From: Thor Lancelot Simon <>
List: tech-kern
Date: 02/25/2003 16:01:38
On Tue, Feb 25, 2003 at 02:58:19PM -0500, Viktor Dukhovni wrote:
> I promised to not follow up to this list, but since others appear to want
> to see the discussion here, I will break my promise and await
> punishment...
> On Tue, 25 Feb 2003, Jaromir Dolecek wrote:
> > > The question is not whether PIPE_BUF == 512 is correct, but rather whether
> > > it is wise? Is inertia the reason to keep it at 512, or is there a
> > > reasonable guess that something might break if it is raised
> >
> > There is no way to change low-watermark for pipes, there is no
> > equivalent of SO_SNDLOWAT for pipes. Pipe cannot be flagged 'writable'
> > before there is PIPE_BUF space in pipe buffer.  Different apps might
> > have different idea of when they want to write more data to pipe.
> > Keeping the writable treshold low is safe bet.
> >
> > Having low PIPE_BUF may actually improve data transfer speed, since
> > the data exchange might be more fluent - writer gets notified early,
> > reader blocks less.
> >
> This assumes that waiting for say 4K to be free would risk starving the
> reader. I am not convinced this is true. The bulk of the clients are using
> stdio and already reading and writing multiples of 4K. Yes it is possible
> that the reader can drain the entire pipe and block before the writer
> makes more data available, but how much more likely is this not to happen
> with the smaller PIPE_BUF. If one wants to ensure that the pipe never
> drains, one must raise the pipe capacity. The atomicity should have little
> effect on whether the reader manages to drain the pipe.

I think we're talking at cross purposes.  Jaromir is talking about the
new pipe implementation, which moves data directly in a way which makes it
difficult for me, at least, to see what exactly the "capacity" of a pipe
would be.

I *think* that in this implementation, if one can write at all, one can
write at least a page: 4K on i386.  Is that not true, Jaromir?  In that 
case, it would seem like raising PIPE_BUF, for this implementation, would 
not be an unreasonable thing to do.