Re: [PATCH v2] perf bench: add --write-size option to sched pipe

[Breno Leitao]

On Tue, May 26, 2026 at 10:22:58PM +0000, Namhyung Kim wrote:
> On Tue, May 26, 2026 at 06:55:33PM +0100, Breno Leitao wrote:
> > hello Namhyung,
> > 
> > On Mon, May 25, 2026 at 09:17:45PM +0000, Namhyung Kim wrote:
> > > On Thu, May 21, 2026 at 09:15:37AM -0700, Breno Leitao wrote:
> > > > +		ret = write(td->pipe_write, td->buf, write_size);
> > > > +		BUG_ON(ret < 0 || (unsigned int)ret != write_size);
> > > >  		ret = read_pipe(td);
> > > > -		BUG_ON(ret != sizeof(int));
> > > > +		BUG_ON(ret < 0 || (unsigned int)ret != write_size);
> > > 
> > > Is it possible to return smaller values than required due to signal or
> > > something?
> > 
> > I tested this on a VM with the patch applied, running the ping-pong with
> > write_size from 4 B up to 1 MiB, including multi-process and single-CPU
> > contention runs (millions of iterations). I observed zero short reads or short
> > writes.
> > 
> > Looking at fs/pipe.c, this matches the kernel behavior for this access pattern:
> > the bench has a single writer per pipe and the pipe capacity is set to
> > write_size, so the writer never has to sleep mid-write, and the kernel does a
> > sync wake of the reader only after the full payload is queued.
> > 
> > EINTR is also not reachable today because the bench installs no signal
> > handlers and nothing in the call chain delivers signals to the workers
> > 
> > At the same time, I understand the concern and If you'd still prefer defensive
> > handling (short-return loop + EINTR retry) I can add it in v3 — happy to either
> > way.
> 
> Thanks for looking into it.  I think it's better to go defensive for any
> unexpected behavior or changes.

Ack, I will respin it, then.

Thanks for the suggestion,
--breno