> 1) Users who experiance variable performance in a compute-intensive
> task might want to investigate which physical memory pages their
> application is using. There could be a cache thrashing problem,
> as Richard demonstrated, or there could be uncached regions of
> memory, as occurs on some x86 configurations.
i dont think that exposing physical details to users is good at all. This
will come and destroy the effect of any possibly kernel-based page
coloring mechanizm. Also it's not complete. But it's a nice and valid
debugging aid.
> 2) Users who experience *incorrect* calculations might look for
> a correlation with physical memory. This can happen; I have seen
> it. Sometimes, with marginal memory chips, the timing is so
> critical that only certain programs fails, and only with certain
> data (gcc is the prime example). It is helpful to know all the
> potential factors when debugging.
>
> 3) I/O problems can also be sensitive to physical memory address.
this is debugging: make it optional and readable by root only.
> Finally, if Richard's patch, or something like it, could be
> used to feed a program that displayed a map of physical memory and
> showed which pages were mapped to which processes, well, that would be
> just too cool!
which btw. already exists, and more (it does it with cacheline accuracy),
take a look at the memleak detector.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/