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: <1453835384.3534.84.camel@gmail.com>
Date:	Tue, 26 Jan 2016 20:09:44 +0100
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Michal Hocko <mhocko@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: fast path cycle muncher (vmstat: make vmstat_updater deferrable
 again and shut down on idle)

On Tue, 2016-01-26 at 12:22 -0600, Christoph Lameter wrote:
> On Tue, 26 Jan 2016, Mike Galbraith wrote:
> 
> > On Tue, 2016-01-26 at 10:26 -0600, Christoph Lameter wrote:
> > > On Tue, 26 Jan 2016, Mike Galbraith wrote:
> > > 
> > > > > Why would the deferring cause this overhead?
> > > > 
> > > > Because we schedule to idle cores aggressively, thus we may pop
> > > > in and
> > > > out of idle at high frequency.
> > > 
> > > Whats the point of going idle if you have things to do soon?
> > 
> > When a task schedules off, how do you know it'll be back at all,
> > much
> > less soon?
> 
> Ok so you are running an artificial benchmark that always gets the
> system running again when it decides to go idle?

The benchmark does not alter the cycle expenditure per event.  The real
world will pay the toll less frequently than the artificial benchmark,
yes, but it will pay nonetheless, and for most, needlessly.  Or?

	-Mike

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ