On Fri, Aug 06, 2004 at 02:01:23PM +0200, Roger Luethi wrote:

Your call, obviously -- do you think it's worthwhile? I didn't CC you
on my initial posting because I wanted to avoid the impression that I am
trying to make this your problem somehow. Priorities as I see them are:
- Document statm content somewhere. I posted a patch to document
  the current state. It could be complemented with a description of
  what it is supposed to do.
- Come to some agreement on what the proper values should be and
  change kernels accordingly. I'm inclined to favor keeping the first two
  (albeit redundant) fields and setting the rest to 0, simply because for
  them too many different de-facto semantics live in exisiting kernels.
  A year ago, the first field was broken in 2.4 as well (not sure if/when
  it got fixed), but I can see why it is useful to keep around until top
  has found a better source. Same for the second field, the only one that
  has always been correct AFAIK.

Some of the 2.4 semantics just don't make sense. I would not find it
difficult to explain what I believe correct semantics to be in a written
document.

The largest barrier is that the accounting has a large code impact.


On Fri, Aug 06, 2004 at 02:01:23PM +0200, Roger Luethi wrote:

- Provide additional information in proc files other than statm.
  The problems with undocumented records are evident, but
  /proc/pid/status may be getting too heavy for frequent parsing. It's
  not realistic to redesign proc at this point, but it would be nice
  to have some documented understanding about the direction of proc
  evolution.

It will likely be easier to merge improvements of /proc/$PID/status as
the operations there are far less frequent and the accounting less
invasive.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>