Re: [PATCH 4/8] proc: export more page flags in /proc/kpageflags

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Sat, 9 May 2009 12:44:09 +0200 Ingo Molnar <mingo@xxxxxxx> wrote:
> 
> > And because it was so crappy to be in /proc we are now also 
> > treating it as a hard ABI, not as a debugfs interface - for that 
> > single app that is using it.
> 
> We'd probably make better progress here were someone to explain 
> what pagemap actually is.
> 
> pagemap is a userspace interface via which application developers 
> (including embedded) can analyse, understand and optimise their 
> use of memory.

IMHO that's really a fancy sentence for: 'to debug how their app 
interacts with the kernel'. Yes, it can be said without the word 
'debug' or 'instrumentation' in it. Maybe it could also be written 
without having any r's in it.

Doing any of that does not change the meaning of the feature though.

> It is not debugging feature at all, let alone a kernel debugging 
> feature.  For this reason it is not appropriate that its 
> interfaces be presented in debugfs.
> 
> Furthermore the main control file for pagemap is in 
> /proc/<pid>/pagemap.  pagemap _cannot_ be put in debugfs because 
> debugfs doesn't maintain the per-process subdirectories in which 
> to place it.  /proc/<pid>/ is exactly the place where the pagemap 
> file should appear.

only if done in a stupid way.

The thing is, nor are all active inodes enumerated in /debug and not 
in /proc either. And we've stopped stuffing new instrumentation into 
/proc about a decade ago and introduced debugfs for that.

_Especially_ when some piece of instrumentation is clearly growing 
in scope and nature, as here.

> Yes, we could place pagemap's two auxiliary files into debugfs but 
> it would be rather stupid to split the feature's control files 
> across two pseudo filesystems, one of which may not even exist.  
> Plus pagemap is not a kernel debugging feature.

That's not what i'm suggesting though.

What i'm suggesting is that there's a zillion ways to enumerate and 
index various kernel objects, doing that in /proc is fundamentally 
wrong. And there's no need to create a per PID/TID directory 
structure in /debug either, to be able to list and access objects by 
their PID.

_Especially_ when the end result is not human-readable to begin 
with, as it is in the pagemap/kpagecount/kpageflags case.

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