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

[Albert Cahalan]

On Fri, 2004-08-06 at 12:34, Roger Luethi wrote:
> On Fri, 06 Aug 2004 08:58:43 -0400, Albert Cahalan wrote:
> > > Hardly. All I was asking this time was to have a documentation fix
> > > merged, though.
> > 
> > Just delete the documentation. I certainly never use it.
> 
> It wasn't written for you.

OK, but the statm file was. (well, for the maintainer
of procps a decade ago)

Everybody else can parse ps output.

> > Since you need the kernel source to get the documentation
> > anyway, you might as well examine the fs/proc/*.c files.
> 
> 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.
The source code needs a few comments.

> > > * statm is broken. It was broken in 2.4 as well, but _differently_. Every
> > >   application that relies on statm forwards wrong information, or at
> > >   the very least needs special casing because the information provided
> > >   in various fields differs between kernel versions.
> > 
> > The kernel has multiple stat() syscalls. At times, they have been
> > broken when dealing with UID values that overflow. Should these
> > system calls have been eliminated? If not, how is this different?
> 
> stat is a well-defined POSIX call.

Sure, and the currently version with wide UID values was
working just fine. POSIX only defines the library interface
anyway. This made the old stat syscalls be non-POSIX crud.

They were part of the ABI. They were fixed.

> > Why? If statm is broken, it should be fixed. Putting the statm
> > data into the status file was dumb, but it's too late now.
> 
> 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
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.

> > 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
commands to see where TRS should be used:

ps v
CMD_ENV=old ps m

Right now, TSIZ is being substituted. That's wrong.
(this is part of the reason why "ps m" was changed)

The top command still tries to display the real trs.

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

> > >> These would be really useful too:
> > >> 1. swap space used
> > >> 2. swap space that would be used if fully paged out
> > >
> > > There are many values that could be interesting or useful. But that
> > > has nothing to do with the abomination that is statm.
> > 
> > These values belong in statm.
> 
> I thought there was no screwing around with the statm format!?

Adding on to the end is always allowed.

You can't change a value to hex, insert a field in the middle,
delete a field, add comments, change the units, and so on.

> > > 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)
New tools can examine the kernel version number.

> > > [ fixed linux-mm address ]
> > 
> > This should have been on linux-kernel in the first place.
> > The linux-mm list is kind of obscure, and doubly so because
> > it isn't on vger.kernel.org.
> 
> This _was_ on linux-kernel in the first place. _You_ added the wrong
> linux-mm address. I don't get your humor.

I'm referring to your original post. I added back linux-mm
because that's where you first brought this up.

> > No, statm is the proper and only place for this data.
> > I certainly don't claim that statm is bug-free code.
> > That's not a reason to discard the whole statm concept.
> 
> 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.
For example, the LRS field should have been fixed when
the ELF binary format support was introduced.


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