linux-kernel - Re: [PATCH v3 0/3] epoll: introduce round robin wakeup mode

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]

Date:	Fri, 27 Feb 2015 13:10:34 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jason Baron <jbaron@...mai.com>
Cc:	Ingo Molnar <mingo@...nel.org>, peterz@...radead.org,
	mingo@...hat.com, viro@...iv.linux.org.uk, normalperson@...t.net,
	davidel@...ilserver.org, mtk.manpages@...il.com,
	luto@...capital.net, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alexander Viro <viro@....linux.org.uk>
Subject: Re: [PATCH v3 0/3] epoll: introduce round robin wakeup mode

On Wed, 25 Feb 2015 11:27:04 -0500 Jason Baron <jbaron@...mai.com> wrote:

> > Libenzi inactive eventpoll appears to be without a 
> > dedicated maintainer since 2011 or so. Is there anyone who 
> > knows the code and its usages in detail and does final ABI 
> > decisions on eventpoll - Andrew, Al or Linus?
> >
> Generally, Andrew and Al do more 'final' reviews here,
> and a lot of others on lkml are always very helpful in
> looking at this code. However, its not always clear, at
> least to me, who I should pester.

Yes, it's a difficult situation.

The 3/3 changelog refers to "EPOLLROUNDROBIN" which I assume is
a leftover from some earlier revision?

I don't really understand the need for rotation/round-robin.  We can
solve the thundering herd via exclusive wakeups, but what is the point
in choosing to wake the task which has been sleeping for the longest
time?  Why is that better than waking the task which has been sleeping
for the *least* time?  That's probably faster as that task's data is
more likely to still be in cache.

The changelogs talks about "starvation" but they don't really say what
this term means in this context, nor why it is a bad thing.

--
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/