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: <5516AE18.1010606@redhat.com>
Date:	Sat, 28 Mar 2015 09:35:20 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
CC:	linux-kernel@...r.kernel.org, lizefan@...wei.com, tj@...nel.org,
	gregkh@...uxfoundation.org
Subject: Re: [PATCH 2/2] show nohz_full cpus in sysfs

On 03/28/2015 12:18 AM, Mike Galbraith wrote:
> On Fri, 2015-03-27 at 17:50 -0400, riel@...hat.com wrote:
>> From: Rik van Riel <riel@...hat.com>
>>
>> Currently there is no way to query which CPUs are in nohz_full
>> mode from userspace.
> 
> Hm, they're both (as of your last set) invariant. 

So are most of the others in /sys/device/system/cpu

That does not make it less useful to discover what
the system setup turned out to be after boot.

> Is this so an HPC app
> can automatically bind itself or something?  You can't have more than
> one such app, or rather if you did, they'd need more than which CPUs are
> HPC capable, they'd need occupancy too, so the query mechanism seems
> kinda useless.  Box driver has to allocate CPUs, and presumably knows
> the configuration of the box (those who don't become ex box drivers).

Knowing what system you bought does not reduce the usefulness
of /proc/cpuinfo.

The CPUs that actually end up isolated or nohz_full can differ
from what was specified on the kernel commandline, and being
able to see which CPUs ended up in the desired state seems useful.

It can be used by programs like irqbalance to avoid binding IRQs
to isolated or nohz_full CPUs, by libvirt to know which CPUs do
not get load balancing of SCHED_OTHER tasks, etc...

-- 
All rights reversed
--
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