Re: [PATCH] msr v3 available

MOLNAR Ingo (mingo@chiara.csoma.elte.hu)
Thu, 28 Jan 1999 19:24:21 +0100 (CET)


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/