lkml.org 
[lkml]   [1999]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.055 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site