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: <55256F92.1010606@ezchip.com>
Date:	Wed, 8 Apr 2015 14:12:34 -0400
From:	Chris Metcalf <cmetcalf@...hip.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Frederic Weisbecker <fweisbec@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Ingo Molnar <mingo@...hat.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] nohz: make nohz_full imply isolcpus

On 04/08/2015 01:27 PM, Peter Zijlstra wrote:
> On Wed, Apr 08, 2015 at 11:21:56AM -0400, Chris Metcalf wrote:
>> Apparently the body of the commit message isn't as clear as it might be :-)
>>
>> It does say the same thing, though, basically that if nohz_full DOESN'T
>> imply isolcpus, that's a bad thing.  I'm happy to reword the text to avoid
>> the double negative and say:
>>
>>    nohz_full is only useful with isolcpus also set, since otherwise the
>>    scheduler has to run periodically to try to determine whether to steal
>>    work from other cores.
> But you're doing the reverse! You're setting nohz_full for isolcpus, not
> limiting the nohz_full mask to isolcpus.

Ah, I see.  Yes, that's right.  The idea is that if you are saying
"nohz_full=1-15" on the command line, you would like that to
imply "isolcpus=1-15" as well, without having to actually say so
explicitly.  If we instead limit nohz_full based on isolcpus, it's not
clear that it's actually worth making any change in this area.

I still maintain that the text has always correctly (if perhaps
confusingly) said what it is that the code was doing; where the
text says "x implies y", that means "x being set forces y to be set".
But I'm respinning it anyway for Frederic so I will avoid using the
word "imply" altogether to make this clearer.

The larger question is whether you agree with the proposed semantics.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

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