On 12/08/2016 04:28 PM, Justin Chen wrote:
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
Justin,
CACHE instruction is not available in user space, only SYNCI on MIPS R2+
for trampoline.
Any operation with CACHE requires a syscall.
As for SYNCI (trampoline from L1D->L1I) the following information in
user space is needed:
1. L1 line size (available via RDHWR $x, $1). It is available now
directly from CPU, but may be better to supply from kernel because some
cores has no that.
2. The flag that L1I is NOT coherent with L1D and SYNCI is needed
and available
The knowledge about L1/L2 sizes is not needed for regular application...
well, if application wants to get advantage of cache sizes, well, in
this case it can be supplied.
But it is unreliable because app may be rescheduled into different kind
of core which has a different L1 size (in heterogeneous system, BTW). It
can be fixed by setting affinity, of course (not sure - can it be
reliably done in BIG/LITTLE approach). But that requires in application
the knowledge and understanding of system CPU structure... well why we
can allow all that stuff besides information purpose? It corrupts the
all efforts and optimization in kernel about performance and powersaving.
Regards,
- Leonid.
