linux-kernel - Re: [patch 0/5] Nano/Microsecond resolution for select() and poll()

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200808291754.28241.arnd@arndb.de>
Date:	Fri, 29 Aug 2008 17:54:27 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...x.de,
	torvalds@...ux-foundation.org,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [patch 0/5] Nano/Microsecond resolution for select() and poll()

On Friday 29 August 2008, Arjan van de Ven wrote:

> With this patch series, the internals of select() and poll() interfaces are
> changed such that they work on the nanosecond level (using hrtimers). The
> userspace interface for select() is in microseconds, for pselect() and
> ppoll() this is in nanoseconds.

Nice work, seems a lot better thought through than my previous attempt [1],
which unfortunately never saw any reactions.
 
> even though poll() (as opposed to ppoll()) only accepts milliseconds
> as userspace interface, the behavior will still improve because the current
> time no longer needs to be rounded up to the next jiffie, so on average
> a 500 milliseconds behavior improvement.

That would be 500 microseconds I think.

> I'd like to get rid of the jiffies timeout entirely over time, and
> only use hrtimers (makes the code a lot nicer) but that's for now
> a separate step, first I'd like to see how this change pans out. 

You mean entirely entirely getting rid of jiffies in the kernel, or just
with user facing interfaces like epoll_wait, rt_sigtimedwait etc?

I think if we want to replace more code with hr timers, we will need
something like dwmw2's range timers based on that in order to keep the
wakeup rate low. These are still jiffies based, which doesn't help
your case, but they should be easy to change to ktime or timespec.

	Arnd <><

[1] http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/1319.html
[2] http://lwn.net/Articles/291159/
--
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/