On Fri, 06 Aug 2004 10:51:24 -0400, Albert Cahalan wrote:

Everybody else can parse ps output.

Not everybody wants to. And ps doesn't provide all the process
information I can get via proc anyway.

quoted

Some users may prefer written documentation over reading the kernel
source. In addition, in the case of statm, there is nothing to document
the expected behavior in the source, either. Which is precisely why
statm has been utterly broken forever.

A correct proc.txt would not have avoided this.

It would have helped some of us confirming our suspicions.

The source code needs a few comments.

Works for me. I'm looking forward to see that fixed.

quoted

It was not dumb. Some people actually prefer human-readable output when
working with proc.

These people shouldn't be working in /proc. It's easier and

Let me be the one to decide when I use a proc file.

more portable to use "ps" for their scripts. You can select
which fields you want, get a header if you like, have the
processes filtered for you, and so on. Look:

ps -U root -u root -o pid= -o ppid= -o args

What's not to like about that? It's portable even.

I wouldn't like ps to be the gatekeeper to proc information. Plus
there's non-portable information in proc that I care about.

quoted

quoted

On AIX:  ps -eo trs
On BSD:  ps axo trss

I trust they take that information from /proc/pid/statm, too?

The point is that the name "trs" has a specific meaning.
The statm file was created to support ps. It wouldn't exist
if ps didn't need to display a TRS column. So the proper
behavior of ps is what defines the meaning. Run these two

Fair enough. I think proc.txt should note this relation between
statm and ps.

quoted

quoted

quoted

quoted

+ dt       number of dirty pages   (always 0 on 2.6)

This one would be useful.

Agreed. It would be nice to have it somewhere else.

No, it's not nice to go moving things around. How about you go

This field is 0 on 2.6. Zero. Always. I am suggesting to have the
information available somewhere. That sure ought to count as an
improvement.

Sure. That "somewhere" should be where it was before.

I wouldn't mind seeing it in /proc/pid/status if the accounting gets
merged.

quoted

quoted

quoted

Hey, I am all _for_ improving proc. But rather than adding more values,
I'd like to address some design problems first: For example, I'd
like to have a reserved value for N/A (currently, kernels just set
obsolete fields to 0 and parsers must guess whether it's truly 0 or not
available).

Don't even think of changing this.

Why not? Got a better solution?

Old tools need a value that will best make them work. (zero)

True for old fields. New fields are a different matter.

New tools can examine the kernel version number.

Right. And every user space tool reading proc needs a database to
remember which field is active in which kernel version.

quoted

The current state of statm code clearly demonstrates the level of
interest in this concept.

It demonstrates that misleading data is hard to spot.
It demonstrates that people hacking on the kernel are
often unconcerned with providing correct stats for others.

I'd agree to some extent, but statm was pretty much impossible to fix
for even the most concerned kernel hacker.

Roger
--
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>