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:	Thu, 03 Sep 2015 03:29:48 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Chris Metcalf <cmetcalf@...hip.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	"Jiang, Yunhong" <yunhong.jiang@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Vatika Harlalka <vatikaharlalka@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Christoph Lameter <cl@...ux.com>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 1/2] nohz: Affine unpinned timers to housekeepers

On Wed, 2015-09-02 at 12:16 -0400, Chris Metcalf wrote:
> On 09/02/2015 05:38 AM, Mike Galbraith wrote:
> > IMHO, nohz_full -> cpu_isolated_map removal really wants to happen.
> > NO_HZ_FULL_ALL currently means "Woohoo, next stop NR_CPUS=0".
> 
> Yeah, the problem seems to be folks who use it as a kind of
> "hey, maybe this gives me some optimization boost somewhere"
> kind of setting.  Did we ever hear actual use cases for people who
> benefited from running nohz_full on cpus with an active scheduler,
> i.e. no isolcpus for that core?  I find it hard to imagine, but, maybe...?

The only sane usage atm is my entire box (small, big likely won't boot)
is a dedicated specialist.  Previously, you could also have had the
feature is valuable enough that I'm willing to pay the quite high price
to have this feature available for whenever I feel like using it.

> If we don't have such use cases, what should we do here?  I'm
> slightly sympathetic to these folks who are going "Gee, my machine
> suddenly got way slower", but only in the same sense as people
> who shoot themselves in the foot and then say "Gee, my foot is
> bleeding".  But maybe I'm being too hard core :-)

I think it's bloody stupid to declare nohz_full cpus dead when they can
in fact do generic work.  There's no reason to do so... unless maybe we
really do need to hold the hand of poor ole Aunt Tilly... the hapless
HPC administrator who can't figure out how to use cpusets or such.  

When the overhead goes away, dynamic usage will become a lot more
_practical_, but you can do it in the here and now modulo the cost and
that bogus death certificate.  They ain't dead, two patches combined to
bury the poor things alive.

	-Mike

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