From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.25.208.137 with SMTP id h131csp2003335lfg; Tue, 10 May 2016 03:31:30 -0700 (PDT) X-Received: by 10.55.48.80 with SMTP id w77mr41929485qkw.7.1462876290856; Tue, 10 May 2016 03:31:30 -0700 (PDT) Return-Path: Received: from lists.gnu.org (lists.gnu.org. [2001:4830:134:3::11]) by mx.google.com with ESMTPS id m186si943495qhb.19.2016.05.10.03.31.30 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 May 2016 03:31:30 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) client-ip=2001:4830:134:3::11; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) smtp.mailfrom=qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org Received: from localhost ([::1]:45661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b04ws-0006Po-Ck for alex.bennee@linaro.org; Tue, 10 May 2016 06:31:30 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b04wA-0005So-5B for qemu-devel@nongnu.org; Tue, 10 May 2016 06:30:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b04w7-0007Vj-TA for qemu-devel@nongnu.org; Tue, 10 May 2016 06:30:45 -0400 Received: from foss.arm.com ([217.140.101.70]:42603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b04w1-0007T5-AB; Tue, 10 May 2016 06:30:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1BC52433; Tue, 10 May 2016 03:24:11 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F6213F252; Tue, 10 May 2016 03:23:57 -0700 (PDT) Date: Tue, 10 May 2016 11:24:04 +0100 From: Will Deacon To: Catalin Marinas Message-ID: <20160510102403.GE22813@arm.com> References: <570B7048.5010501@arm.com> <570E1866.9010201@arm.com> <57306DA7.4010002@arm.com> <20160509134410.GA2504@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160509134410.GA2504@localhost.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 217.140.101.70 Subject: Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Vijay Kilari , Suzuki K Poulose , Vijaya Kumar K , suresh knv , Vijaya Kumar K , QEMU Developers , Prasun Kapoor , qemu-arm , Suresh , Paolo Bonzini Errors-To: qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-devel" X-TUID: BRfSETtVl0c2 On Mon, May 09, 2016 at 01:44:11PM +0000, Catalin Marinas wrote: > On Mon, May 09, 2016 at 12:21:08PM +0100, Peter Maydell wrote: > > On 9 May 2016 at 11:59, Suzuki K Poulose wrote: > > > Well, we have been waiting for a use case, like this, before we merge > > > the series. > > > > This isn't a great strategy for moving people away from things > > you'd like them to avoid like parsing /proc/cpuinfo, because typically > > userspace app writers are not very interested in coding to facilities > > which don't exist yet, and will prefer to make do with what's actually > > present in the kernel today... You need to provide the improved API, > > and then it needs to get out into kernel versions in distros and > > otherwise, and only then are you likely to get app developers who > > will start to say "this is useful". > > The problem is that the way kernel people think the API may be improved > does not always match the use-cases required by app writers. One example > here is exposing MIDR via MRS emulation, we know there are problems with > big.LITTLE and the only clear answer I got so far is that we ignore such > configurations. We don't even have a way to tell user space that this is > a heterogeneous CPU configuration, unless we add another HWCAP bit > specifically for this (or the opposite: HWCAP_HOMOGENEOUS_CPUS). Personally, I think we should expose big.LITTLE as-is to userspace. That is, if you execute an mrs instruction you'll get whichever core the emulation happens to run on. This might even be useful to things like pinned threadpools w/ userspace schedulers sitting on top. > That said, I'm perfectly fine with exposing: > > /sys/devices/system/cpu/cpu$ID/identification/ > \- midr > \- revidr > > I had the wrong impression that we already merged this part but Suzuki > just pointed out to me that it's not. Yes, there are use-cases for this interface as well. I don't think it's a choice between one or the other and I firmly believe we need both (the sysfs and mrs code). > I think our 4.7-rc1 tree is pretty much frozen to new features now, > though the sysfs patch is relatively small (I'll let Will comment): The merge window opens in less than a week, so it's fixes only atm. Will From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b04wA-0005So-5B for qemu-devel@nongnu.org; Tue, 10 May 2016 06:30:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b04w7-0007Vj-TA for qemu-devel@nongnu.org; Tue, 10 May 2016 06:30:45 -0400 Date: Tue, 10 May 2016 11:24:04 +0100 From: Will Deacon Message-ID: <20160510102403.GE22813@arm.com> References: <570B7048.5010501@arm.com> <570E1866.9010201@arm.com> <57306DA7.4010002@arm.com> <20160509134410.GA2504@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160509134410.GA2504@localhost.localdomain> Subject: Re: [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Catalin Marinas Cc: Peter Maydell , Suzuki K Poulose , Vijay Kilari , Vijaya Kumar K , qemu-arm , Paolo Bonzini , QEMU Developers , Prasun Kapoor , suresh knv , Vijaya Kumar K , Suresh On Mon, May 09, 2016 at 01:44:11PM +0000, Catalin Marinas wrote: > On Mon, May 09, 2016 at 12:21:08PM +0100, Peter Maydell wrote: > > On 9 May 2016 at 11:59, Suzuki K Poulose wrote: > > > Well, we have been waiting for a use case, like this, before we merge > > > the series. > > > > This isn't a great strategy for moving people away from things > > you'd like them to avoid like parsing /proc/cpuinfo, because typically > > userspace app writers are not very interested in coding to facilities > > which don't exist yet, and will prefer to make do with what's actually > > present in the kernel today... You need to provide the improved API, > > and then it needs to get out into kernel versions in distros and > > otherwise, and only then are you likely to get app developers who > > will start to say "this is useful". > > The problem is that the way kernel people think the API may be improved > does not always match the use-cases required by app writers. One example > here is exposing MIDR via MRS emulation, we know there are problems with > big.LITTLE and the only clear answer I got so far is that we ignore such > configurations. We don't even have a way to tell user space that this is > a heterogeneous CPU configuration, unless we add another HWCAP bit > specifically for this (or the opposite: HWCAP_HOMOGENEOUS_CPUS). Personally, I think we should expose big.LITTLE as-is to userspace. That is, if you execute an mrs instruction you'll get whichever core the emulation happens to run on. This might even be useful to things like pinned threadpools w/ userspace schedulers sitting on top. > That said, I'm perfectly fine with exposing: > > /sys/devices/system/cpu/cpu$ID/identification/ > \- midr > \- revidr > > I had the wrong impression that we already merged this part but Suzuki > just pointed out to me that it's not. Yes, there are use-cases for this interface as well. I don't think it's a choice between one or the other and I firmly believe we need both (the sysfs and mrs code). > I think our 4.7-rc1 tree is pretty much frozen to new features now, > though the sysfs patch is relatively small (I'll let Will comment): The merge window opens in less than a week, so it's fixes only atm. Will