linux-kernel - Re: [PATCH 0/4] pending scheduler updates

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1224669821.6871.16.camel@marge.simson.net>
Date:	Wed, 22 Oct 2008 12:03:41 +0200
From:	Mike Galbraith <efault@....de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] pending scheduler updates

On Wed, 2008-10-22 at 11:40 +0200, Ingo Molnar wrote:
> * Srivatsa Vaddagiri <vatsa@...ibm.com> wrote:
> 
> > On Mon, Oct 20, 2008 at 02:05:38PM +0200, Ingo Molnar wrote:
> > > 
> > > * Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> > > 
> > > > Please apply
> > > 
> > > applied these to tip/sched/urgent:
> > > 
> > >  f9c0b09: sched: revert back to per-rq vruntime
> > >  a4c2f00: sched: fair scheduler should not resched rt tasks
> > >  ffda12a: sched: optimize group load balancer
> > > 
> > > (will wait with 4/4 until you and Mike come to a verdict.)
> > 
> > Is there any conclusion on Patch 4/4? It looks sane to me!
> 
> Mike?

Your call of course, but I don't think it's a good trade.  In testing,
it does serious injury to mysql+oltp peak throughput, and slows down
things which need frequent preemption in order to compete effectively
against hogs.  (includes desktop, though that's not heavily tested)

The attached starvation testcase, distilled from real app and posted to
lkml a few years ago, it totally kills.  It's a worst case scenario to
be sure, but that worst case is pretty dramatic.  I guesstimated it
would take ~12 hours for it to do 10M signals with wakeup preemption so
restricted, vs 43 seconds with preemption as is.  To me, that suggests
that anything ultra fast/light will pay through the nose.

It has positive effects too, but IMHO, the bad outweigh the good.

	-Mike

View attachment "starve.c" of type "text/x-csrc" (716 bytes)