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:	Wed, 26 Aug 2009 21:32:52 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	raz ben yehuda <raziebe@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Mike Galbraith <efault@....de>, riel@...hat.com,
	andrew motron <akpm@...ux-foundation.org>,
	wiseman@...s.biu.ac.il, lkml <linux-kernel@...r.kernel.org>,
	linux-rt-users@...r.kernel.org
Subject: Re: RFC: THE OFFLINE SCHEDULER


* Christoph Lameter <cl@...ux-foundation.org> wrote:

> On Wed, 26 Aug 2009, Ingo Molnar wrote:
> 
> > The thing is, you have cut out (and have not replied to) this
> > crutial bit of what Peter wrote:
> >
> > > > The past year or so you've been whining about the tick latency,
> > > > and I've seen exactly _0_ patches from you slimming down the
> > > > work done in there, even though I pointed out some obvious
> > > > things that could be done.
> >
> > ... which pretty much settles the issue as far as i'm concerned. 
> > If you were truly interested in a constructive solution to lower 
> > latencies in Linux you should have sent patches already for the 
> > low hanging fruits Peter pointed out.
> 
> The noise latencies were already reduced in years earlier to the 
> mininum (f.e. the work on slab queue cleaning). Certainly more 
> could be done there but that misses the point.

Peter suggested various improvements to the timer tick related 
latencies _you_ were complaining about earlier this year. Those 
latencies sure were not addressed 'years earlier'.

If you are unwilling to reduce the very latencies you apparently 
cared and complained about then you dont have much real standing to 
complain now.

( If you on the other hand were approaching this issue with 
  pragmatism and with intellectual honesty, if you were at the end 
  of a string of patches that gradually improved latencies but 
  couldnt get them below a certain threshold, and if scheduler 
  developers couldnt give you any ideas what else to improve, and 
  _then_ suggested some other solution, you might have a point.
  You are far away from being able to claim that. )

Really, it's a straightforward application of Occam's Razor to the 
scheduler. We go for the simplest solution first, and try to help 
more people first, before going for some specialist hack.

> The point of the OFFLINE scheduler is to completely eliminate the 
> OS disturbances by getting rid of *all* OS processing on some 
> cpus.
> 
> For some reason scheduler developers seem to be threatened by this 
> idea and they go into bizarre lines of arguments to avoid the 
> issue. Its simple and doable and the scheduler will still be there 
> after we do this.

If you meant to include me in that summary categorization, i dont 
feel 'threatened' by any such patches (why would i? They dont seem 
to have sharp teeth nor any apparent poison fangs) - i simply concur 
with the reasons Peter listed that it is a technically inferior 
solution.

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