On Thu, Dec 8, 2016 at 3:26 PM, Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx> wrote: > On 12/07/2016 05:16 PM, Justin Chen wrote: >> >> From: Justin Chen <justin.chen@xxxxxxxxxxxx> >> >> Add cacheinfo support for MIPS architectures. >> >> Use information from the cpuinfo_mips struct to populate the >> cacheinfo struct. This allows an architecture agnostic approach, >> however this also means if cache information is not properly >> populated within the cpuinfo_mips struct, there is nothing >> we can do. (I.E. c-r3k.c) >> >> > > Justin, for architecture agnostic approach of work with caches the > cpuinfo_mips lacks more information: > > 1. L1I-L1D coherency status (is L1I coherent to L1D) > 2. L1D-L2 coherency status (is L1D coherent to L2) > 3. L1I-L2 coherency status (is L1I coherent to L2) > 4. L1I refill from L1D (snoops L1D) or L2 (may require L1D flush)? > 5. L1D cache aliasing disabled by HW > 6. L1I cache aliasing disabled by HW > 7. Barrier existence and it's type between various cache flushes as is as > between cache flush and final (completed) state. > 8. Cache ownership (current: assumed that sibling CPUs share L1 - may be > shared_cpu_map?) > 9. Is address cache flush operation global in system or pure local? > 10. Is index cache flush operation global in system or pure local? > > Without that the proposed cpuinfo_mips struct is basically useless. > > Regards, > - Leonid Thanks for the comments Leonid. We should consider the scope of this patch. The information we are trying to expose to userspace is limited to the struct cacheinfo located at include/linux/cacheinfo.c (of course this can always be expanded). So the question is what information would be useful to expose to userspace. Some justification for exposing the current information in the cacheinfo struct could be: (Pulled from another email chain) "Agreed. So far I have got requests from GCC, JIT and graphics guys. IIUC they need this to support cache flushing for user applications like gcc trampolines and JIT compilers. I am also told that having knowledge of cache architecture can help optimal code strategies, though I don't have much details on that." https://patchwork.kernel.org/patch/5867721/ There may be justification for including the points you mentioned above, but I believe that is outside the scope of this patch. The cache information exposed in this patch is limited, but I do not believe it is useless. The points above can be added, but it will require a rework of the base cacheinfo driver. driver/base/cacheinfo.c Thanks, Justin
