From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753318AbbC1Nfg (ORCPT ); Sat, 28 Mar 2015 09:35:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42498 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752573AbbC1Nfe (ORCPT ); Sat, 28 Mar 2015 09:35:34 -0400 Message-ID: <5516AE18.1010606@redhat.com> Date: Sat, 28 Mar 2015 09:35:20 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mike Galbraith CC: linux-kernel@vger.kernel.org, lizefan@huawei.com, tj@kernel.org, gregkh@linuxfoundation.org Subject: Re: [PATCH 2/2] show nohz_full cpus in sysfs References: <1427493027-15955-1-git-send-email-riel@redhat.com> <1427493027-15955-3-git-send-email-riel@redhat.com> <1427516297.2447.59.camel@gmail.com> In-Reply-To: <1427516297.2447.59.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/28/2015 12:18 AM, Mike Galbraith wrote: > On Fri, 2015-03-27 at 17:50 -0400, riel@redhat.com wrote: >> From: Rik van Riel >> >> 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