Re: IPC between application and xserver is causing extra context switches

[Peter Zijlstra <peterz@infradead.org>]

On Fri, 2010-09-03 at 17:24 +0300, Pauli Nieminen wrote:
> On 03/09/10 09:31 +0200, ext Peter Zijlstra wrote:
> > On Fri, 2010-09-03 at 10:17 +0300, Pauli Nieminen wrote:
> > > Scheduling at write is wrong because xserver doesn't know about client
> > > priorities. 
> > 
> > Waking up the client at write is correct because you don't know if there
> > is more to be written.
> > 
> 
> IMO xserver is already signaling kernel when there is nothing more to write.
> There is nothing more to write when xserver calls select after processing
> request and writing responses.
> 
> O_NONBLOCK is set for file descriptors if it matters.
> 
> syscalls will be:
> 
> select(all_fds);
> 
> read(2, ...);
> read(5, ...);
> 
> writev(3, ...);
> writev(5, ...);
> writev(6, ...);
> 
> select(all_fds);
> 
> Of course this is a lot simplified what really happens.

I don't see how that is relevant to anything, POSIX certainly doesn't
mandate anything like that, hence we need to wake up the receiving side
as soon as data arrives.

Scheduling can happen at _any_ time, not only system calls. Waking a
task happens at the moment its blocking condition changes.

In particular, the other process' select()/read() blocks until there is
data available (or a signal arrives), the write() provides data,
therefore a wakeup happens.

The POSIX task model allows for full non-voluntary preemption and Linux
takes full advantage of that.

An application assuming anything else for correct execution is broken.