Cc'ing Ramana to get some input from the toolchain side. On Tue, May 10, 2016 at 11:24:04AM +0100, Will Deacon wrote: > 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's the point I try to make. We "think" there may be use-cases but there are no concrete examples yet. IIRC, the only request for mrs handling came from the tools guys for the ifunc support. However, they don't seem to have a solution for big.LITTLE either and they may simply ignore this feature. OTOH, we have to maintain it in the kernel on the long run because it became ABI (that said, I would be fine if this was complemented by another HWCAP bit for heterogeneous systems). The CPU feature registers wouldn't be affected by the big.LITTLE configurations as we provide a sanitised version anyway. But, again, do we have concrete use-cases? > > 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). At least for this one we have a clear use-case: JVM and errata workarounds. > > 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. We have more time to debate ;) -- Catalin
