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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 03 Sep 2010 17:30:43 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Pauli Nieminen <ext-pauli.nieminen@...ia.com>
Cc:	ext Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Tony Lindgren <tony@...mide.com>,
	Jarkko Nikula <jhnikula@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pauli <suokkos@...il.com>
Subject: Re: IPC between application and xserver is causing extra context
 switches

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/