Re: [proc.txt] Fix /proc/pid/statm documentation

[Roger Luethi]

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.

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

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

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

> > > >> + 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.

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

> > 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/