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 <suzuki.poul...@arm.com> 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