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