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]
Message-ID: <1283527843.2050.161.camel@laptop>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ