On Fri, 2019-07-12 at 09:56 +0100, Russell King - ARM Linux admin wrote: > On Fri, Jul 12, 2019 at 02:58:18AM +0000, Raslan, KarimAllah wrote: > > > > On Fri, 2019-07-12 at 08:06 +0530, Anshuman Khandual wrote: > > > > > > > > > On 07/12/2019 03:51 AM, KarimAllah Ahmed wrote: > > > > > > > > > > > > Some valid RAM can live outside kernel control (e.g. using mem= kernel > > > > command-line). For these regions, pfn_valid would return "false" causing > > > > system RAM to be mapped as uncached. Use memblock instead to identify > > > > RAM. > > > > > > Once the remaining memory is outside of the kernel (as the admin would > > > have > > > intended with mem= command line) what is the particular concern regarding > > > the way those get mapped (cached or not) ? It is not to be used any way. > > > > They can be used by user-space which might lead to them being used by the > > kernel. One use-case would be using them as guest memory for KVM as I > > detailed > > here: > > > > https://lwn.net/Articles/778240/ > > From the 32-bit ARM point of view... > > What if someone's already doing something similar with a non-coherent > DSP and is relying on the current behaviour? This change is a user > visible behavioural change that could end up breaking userspace. > > In other words, it isn't something we should rush into.
Yes, that makes sense. How about adding a command-line option for this new behavior instead? Would this be more reasonable? Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879