Messages in this thread | | | Date | Thu, 28 Jan 1999 19:24:21 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: [PATCH] msr v3 available |
| |
On Thu, 28 Jan 1999, Craig Milo Rogers wrote:
> 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/
| |