proc: export more page flags in /proc/kpageflags (take 4)

Some bit ranges were inclusive and some not.
Fix them to be consistently inclusive.

Signed-off-by Wu Fengguang <[email protected]>

---
 Documentation/vm/pagemap.txt |    6 +++---

 1 file changed, 3 insertions(+), 3 deletions(-)

Documentation/vm/pagemap.txt +0 -0

@@ -12,9 +12,9 @@ There are three components to pagemap:

   value for each virtual page, containing the following data (from fs/proc/task_mmu.c, above pagemap_read):

-    * Bits 0-55  page frame number (PFN) if present
+    * Bits 0-54  page frame number (PFN) if present
    * Bits 0-4   swap type if swapped
-    * Bits 5-55  swap offset if swapped
+    * Bits 5-54  swap offset if swapped
    * Bits 55-60 page shift (page size = 1<<page shift)
    * Bit  61    reserved for future use
    * Bit  62    page swapped

Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.

1) for kernel hackers (on CONFIG_DEBUG_KERNEL)
- all available page flags are exported, and
- exported as is
2) for admins and end users
- only the more `well known' flags are exported:
11. KPF_MMAP (pseudo flag) memory mapped page
12. KPF_ANON (pseudo flag) memory mapped page (anonymous)
13. KPF_SWAPCACHE page is in swap cache
14. KPF_SWAPBACKED page is swap/RAM backed
15. KPF_COMPOUND_HEAD (*)
16. KPF_COMPOUND_TAIL (*)
17. KPF_UNEVICTABLE page is in the unevictable LRU list
18. KPF_HWPOISON hardware detected corruption
19. KPF_NOPAGE (pseudo flag) no page frame at the address

(*) For compound pages, exporting _both_ head/tail info enables
users to tell where a compound page starts/ends, and its order.

- limit flags to their typical usage scenario, as indicated by KOSAKI:
- LRU pages: only export relevant flags
- PG_lru
- PG_unevictable
- PG_active
- PG_referenced
- page_mapped()
- PageAnon()
- PG_swapcache
- PG_swapbacked
- PG_reclaim
- no-IO pages: mask out irrelevant flags
- PG_dirty
- PG_uptodate
- PG_writeback
- SLAB pages: mask out overloaded flags:
- PG_error
- PG_active
- PG_private
- PG_reclaim: mask out the overloaded PG_readahead
- compound flags: only export huge/gigantic pages

Here are the admin/linus views of all page flags on a newly booted nfs-root system:

# ./page-types # for admin
         flags  page-count       MB  symbolic-flags                     long-symbolic-flags
0x000000000000      491174     1918  ____________________________                
0x000000000020           1        0  _____l______________________       lru      
0x000000000028        2543        9  ___U_l______________________       uptodate,lru
0x00000000002c        5288       20  __RU_l______________________       referenced,uptodate,lru
0x000000004060           1        0  _____lA_______b_____________       lru,active,swapbacked

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation

measures are being accepted into the MM while other, more dynamic

Quoted 2 lines

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation

I think because it has zero fast path overhead and can be used any time without enabling anything special.

Yes, zero overhead is important for certain things (like CONFIG_SLUB_STATS, for example). However, putting slab allocator specific checks in fs/proc looks pretty fragile to me. It would be nice

Also, while you probably don't want to use tracepoints for this kind of instrumentation, you might want to look into reusing the ftrace reporting bits.

Quoted 3 lines

Yes, zero overhead is important for certain things (like CONFIG_SLUB_STATS, for example). However, putting slab allocator specific checks in fs/proc looks pretty fragile to me. It would be nice

Ok, perhaps that could be put into a inline into slab.h. Would that address your concerns?

Quoted 3 lines

Also, while you probably don't want to use tracepoints for this kind of instrumentation, you might want to look into reusing the ftrace reporting bits.

There's already perfectly fine code in tree for this, I don't see why it would need another infrastructure that doesn't really fit anyways.

Hi Andi,

Quoted 5 lines · Andi Kleen

Quoted 2 lines

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation

I think because it has zero fast path overhead and can be used any time without enabling anything special.

Yes, zero overhead is important for certain things (like CONFIG_SLUB_STATS, for example). However, putting slab allocator specific checks in fs/proc looks pretty fragile to me. It would be nice to have this under the "kmemtrace umbrella" so that there's just one place that needs to be fixed up when allocators change.

Also, while you probably don't want to use tracepoints for this kind of instrumentation, you might want to look into reusing the ftrace reporting bits.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation

Quoted 2 lines

Quoted 2 lines

I think because it has zero fast path overhead and can be used any time without enabling anything special.

( That's a dubious claim in any case - tracepoints are very cheap. And they could be made even cheaper and such efforts would benefit all the tracepoint users so it's a prime focus of interest. Andi is a SystemTap proponent, right? I saw him oppose pretty much everything built-in kernel tracing related. I consider that a pretty extreme position. )

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I think because it has zero fast path overhead and can be used any time without enabling anything special.

Quoted 6 lines · Ingo Molnar

( That's a dubious claim in any case - tracepoints are very cheap. And they could be made even cheaper and such efforts would benefit all the tracepoint users so it's a prime focus of interest. Andi is a SystemTap proponent, right? I saw him oppose pretty much everything built-in kernel tracing related. I consider that a pretty extreme position. )

I have no idea how expensive tracepoints are but I suspect they don't make too much sense for this particular scenario. After all, kmemtrace is mainly interested in _allocation patterns_ whereas this patch seems to be more interested in "memory layout" type of things.

Quoted 5 lines

I have no idea how expensive tracepoints are but I suspect they don't make too much sense for this particular scenario. After all, kmemtrace is mainly interested in _allocation patterns_ whereas this patch seems to be more interested in "memory layout" type of things.

That said, I do foresee a need to be able to turn on more detailed tracing after you've identified problematic areas from kpageflags type of overview report. And for that, you almost certainly want kmemtrace/tracepoints style solution with pid/function/whatever regexp matching ftrace already provides.

I 'integrate' traces all the time to get summary counts. This series of dynamic events:

 allocation
 page count up
 page count up
 page count down
 page count up
 page count up
 page count up
 page count up

integrates into: "page count is 6".

Note that "integration" can be done wholly in the kernel too, without going to the overhead of streaming all dynamic events to user-space, just to summarize data into counts, in-kernel. That is what the ftrace statistics framework and various ftrace plugins are about.

Also, it might make sense to extend the framework with a series of 'get current object state' events when tracing is turned on. A special case of _that_ would in essence be what the /proc hack does now - just expressed in a much more generic, and a much more usable form.

I guess the main question here is whether this approach will scale to something like kmalloc() or the page allocator in production environments. For any serious workload, the frequency of events is going to be pretty high.

Quoted 4 lines

I guess the main question here is whether this approach will scale to something like kmalloc() or the page allocator in production environments. For any serious workload, the frequency of events is going to be pretty high.

Immediate Values patch series makes zero-overhead to tracepoint while it's not used.

So, We have to implement to stop collect stastics way. it restore zero overhead world.
We don't lose any performance by trace.

Hi!

2009/4/28 KOSAKI Motohiro <[email protected]>:

Quoted 11 lines

Quoted 4 lines

I guess the main question here is whether this approach will scale to something like kmalloc() or the page allocator in production environments. For any serious workload, the frequency of events is going to be pretty high.

Immediate Values patch series makes zero-overhead to tracepoint while it's not used.

So, We have to implement to stop collect stastics way. it restore zero overhead world.
We don't lose any performance by trace.

Sure but I meant the _enabled_ case here. kmalloc() (and the page allocator to some extent) is very performance sensitive in many workloads so you probably don't want to use tracepoints if you're collecting some overall statistics (i.e. tracing all events) like we do here.

Quoted 16 lines

Hi!

2009/4/28 KOSAKI Motohiro <[email protected]>:

Quoted 11 lines

Quoted 4 lines

I guess the main question here is whether this approach will scale to something like kmalloc() or the page allocator in production environments. For any serious workload, the frequency of events is going to be pretty high.

Immediate Values patch series makes zero-overhead to tracepoint while it's not used.

So, We have to implement to stop collect stastics way. it restore zero overhead world.
We don't lose any performance by trace.

Quoted 5 lines

Sure but I meant the _enabled_ case here. kmalloc() (and the page allocator to some extent) is very performance sensitive in many workloads so you probably don't want to use tracepoints if you're collecting some overall statistics (i.e. tracing all events) like we do here.

That's where 'collect current state' kind of tracepoints would help
- they could be used even without enabling any of the other tracepoints. And they'd still be in a coherent whole with the dynamic-events tracepoints.

So i'm not arguing against these techniques at all - and we can move on a wide scale from zero-overhead to lots-of-tracing-enabled models
- what i'm arguing against is the splintering.

2009/4/28 Ingo Molnar <[email protected]>:

Quoted 24 lines · Pekka Enberg

Quoted 16 lines

Hi!

2009/4/28 KOSAKI Motohiro <[email protected]>:

Quoted 11 lines

Quoted 4 lines

I guess the main question here is whether this approach will scale to something like kmalloc() or the page allocator in production environments. For any serious workload, the frequency of events is going to be pretty high.

Immediate Values patch series makes zero-overhead to tracepoint while it's not used.

So, We have to implement to stop collect stastics way. it restore zero overhead world.
We don't lose any performance by trace.

Quoted 5 lines

Sure but I meant the _enabled_ case here. kmalloc() (and the page allocator to some extent) is very performance sensitive in many workloads so you probably don't want to use tracepoints if you're collecting some overall statistics (i.e. tracing all events) like we do here.

Quoted 8 lines

That's where 'collect current state' kind of tracepoints would help
- they could be used even without enabling any of the other tracepoints. And they'd still be in a coherent whole with the dynamic-events tracepoints.

So i'm not arguing against these techniques at all - and we can move on a wide scale from zero-overhead to lots-of-tracing-enabled models
- what i'm arguing against is the splintering.

umm.
I guess Pekka and you talk about different thing.

if tracepoint is ON, tracepoint makes one function call. but few hot spot don't have patience to one function call overhead.

scheduler stat and slab stat are one of good example, I think.

I really don't want convert slab_stat and sched_stat to ftrace base stastics. currently it don't need extra function call and it only touch per-cpu variable. So, a overhead is extream small.

Unfortunately, tracepoint still don't reach this extream performance.

Hi Ingo,

Quoted 20 lines · Ingo Molnar

I 'integrate' traces all the time to get summary counts. This series of dynamic events:

allocation
page count up
page count up
page count down
page count up
page count up
page count up
page count up

integrates into: "page count is 6".

Note that "integration" can be done wholly in the kernel too, without going to the overhead of streaming all dynamic events to user-space, just to summarize data into counts, in-kernel. That is what the ftrace statistics framework and various ftrace plugins are about.

Quoted 5 lines

Also, it might make sense to extend the framework with a series of 'get current object state' events when tracing is turned on. A special case of _that_ would in essence be what the /proc hack does now - just expressed in a much more generic, and a much more usable form.

I guess the main question here is whether this approach will scale to something like kmalloc() or the page allocator in production environments. For any serious workload, the frequency of events is going to be pretty high.

I 'integrate' traces all the time to get summary counts. This series of dynamic events:

allocation
page count up
page count up
page count down
page count up
page count up
page count up
page count up

integrates into: "page count is 6".

Quoted 2 lines · Andi Kleen

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation

Quoted 10 lines · Pekka Enberg

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I think because it has zero fast path overhead and can be used any time without enabling anything special.

Quoted 6 lines · Ingo Molnar

( That's a dubious claim in any case - tracepoints are very cheap. A And they could be made even cheaper and such efforts would benefit A all the tracepoint users so it's a prime focus of interest. A Andi is a SystemTap proponent, right? I saw him oppose pretty much A everything built-in kernel tracing related. I consider that a A pretty extreme position. )

Quoted 4 lines · Pekka Enberg

I have no idea how expensive tracepoints are but I suspect they don't make too much sense for this particular scenario. After all, kmemtrace is mainly interested in _allocation patterns_ whereas this patch seems to be more interested in "memory layout" type of things.

That said, I do foresee a need to be able to turn on more detailed tracing after you've identified problematic areas from kpageflags type of overview report. And for that, you almost certainly want kmemtrace/tracepoints style solution with pid/function/whatever regexp matching ftrace already provides.

I have no idea how expensive tracepoints are but I suspect they don't make too much sense for this particular scenario. After all, kmemtrace is mainly interested in _allocation patterns_ whereas this patch seems to be more interested in "memory layout" type of things.

Quoted 6 lines

I have no idea how expensive tracepoints are but I suspect they don't make too much sense for this particular scenario. After all, kmemtrace is mainly interested in _allocation patterns_ whereas this patch seems to be more interested in "memory layout" type of things.

My point is that the allocation patterns can be derived from dynamic events. We can build a map of everything if we know all the events that led up to it. Doing:

echo 3 > /proc/sys/vm/drop_caches

will clear 99% of the memory allocations, so we can build a new map from scratch just about anytime. (and if boot allocations are interesting they can be traced too)

_And_ via this angle we'll also have access to the dynamic events, in a different 'view' of the same tracepoints - which is obviously very useful for different purposes.

Quoted 19 lines · Pekka Enberg

Quoted 6 lines

I have no idea how expensive tracepoints are but I suspect they don't make too much sense for this particular scenario. After all, kmemtrace is mainly interested in _allocation patterns_ whereas this patch seems to be more interested in "memory layout" type of things.

My point is that the allocation patterns can be derived from dynamic events. We can build a map of everything if we know all the events that led up to it. Doing:

echo 3 > /proc/sys/vm/drop_caches

will clear 99% of the memory allocations, so we can build a new map from scratch just about anytime. (and if boot allocations are interesting they can be traced too)

Quoted 3 lines

_And_ via this angle we'll also have access to the dynamic events, in a different 'view' of the same tracepoints - which is obviously very useful for different purposes.

I am one of most strongly want guys to MM tracepoint. but No, many cunstomer never permit to use drop_caches.

Quoted 23 lines · KOSAKI Motohiro

Quoted 22 lines · Pekka Enberg

Quoted 6 lines

I have no idea how expensive tracepoints are but I suspect they don't make too much sense for this particular scenario. After all, kmemtrace is mainly interested in _allocation patterns_ whereas this patch seems to be more interested in "memory layout" type of things.

My point is that the allocation patterns can be derived from dynamic events. We can build a map of everything if we know all the events that led up to it. Doing:

echo 3 > /proc/sys/vm/drop_caches

will clear 99% of the memory allocations, so we can build a new map from scratch just about anytime. (and if boot allocations are interesting they can be traced too)

_And_ via this angle we'll also have access to the dynamic events, in a different 'view' of the same tracepoints - which is obviously very useful for different purposes.

Quoted 2 lines

I am one of most strongly want guys to MM tracepoint. but No, many cunstomer never permit to use drop_caches.

See my other mail i just sent: it would be a natural extension of tracing to also dump all current object state when tracing is turned on. That way no drop_caches is needed at all.

But it has to be expressed in one framework that cares about the totality of the kernel - not just these splintered bits of instrumentation and pieces of statistics.

Quoted 6 lines

Quoted 2 lines

I am one of most strongly want guys to MM tracepoint. but No, many cunstomer never permit to use drop_caches.

See my other mail i just sent: it would be a natural extension of tracing to also dump all current object state when tracing is turned on. That way no drop_caches is needed at all.

I can understand the merits here - I also did readahead tracing/accounting in _one_ piece of code. Very handy.

The readahead traces are now raw printks - converting to the ftrace framework would be a big win.

But. It's still not a fit-all solution. Imagine when full data _since_ booting is required, but the user cannot afford a reboot.

Quoted 3 lines

But it has to be expressed in one framework that cares about the totality of the kernel - not just these splintered bits of instrumentation and pieces of statistics.

Though minded to push the kpageflags interface, I totally agree the above fine principle and discipline :-)

Quoted 3 lines

See my other mail i just sent: it would be a natural extension of tracing to also dump all current object state when tracing is turned on. That way no drop_caches is needed at all.

I can understand the merits here - I also did readahead tracing/accounting in _one_ piece of code. Very handy.

The readahead traces are now raw printks - converting to the ftrace framework would be a big win.

But. It's still not a fit-all solution. Imagine when full data _since_ booting is required, but the user cannot afford a reboot.

Quoted 10 lines · Wu Fengguang

Quoted 3 lines

See my other mail i just sent: it would be a natural extension of tracing to also dump all current object state when tracing is turned on. That way no drop_caches is needed at all.

I can understand the merits here - I also did readahead tracing/accounting in _one_ piece of code. Very handy.

The readahead traces are now raw printks - converting to the ftrace framework would be a big win.

Quoted 2 lines

But. It's still not a fit-all solution. Imagine when full data _since_ booting is required, but the user cannot afford a reboot.

The above 'get object state' interface (which allows passive sampling) - integrated into the tracing framework - would serve that goal, agreed?

Quoted 3 lines

The above 'get object state' interface (which allows passive sampling) - integrated into the tracing framework - would serve that goal, agreed?

Agreed. That could in theory a good complement to dynamic tracings.

Then what will be the canonical form for all the 'get object state' interfaces - "object.attr=value", or whatever? [...]

tent-Transfer-Encoding: quoted-printable
Status: RO
Content-Length: 5480
Lines: 161

Quoted 9 lines · Wu Fengguang

Quoted 3 lines

The above 'get object state' interface (which allows passive sampling) - integrated into the tracing framework - would serve that goal, agreed?

Agreed. That could in theory a good complement to dynamic tracings.

Then what will be the canonical form for all the 'get object state' interfaces - "object.attr=value", or whatever? [...]

Lemme outline what i'm thinking of.

I'd call the feature "object collection tracing", which would live in /debug/tracing, accessed via such files:

/debug/tracing/objects/mm/pages/
/debug/tracing/objects/mm/pages/format
/debug/tracing/objects/mm/pages/filter
/debug/tracing/objects/mm/pages/trace_pipe
/debug/tracing/objects/mm/pages/stats
/debug/tracing/objects/mm/pages/events/

here's the (proposed) semantics of those files:

1) /debug/tracing/objects/mm/pages/

There's a subsystem / object basic directory structure to make it easy and intuitive to find our way around there.

2) /debug/tracing/objects/mm/pages/format

the format file:

/debug/tracing/objects/mm/pages/format

Would reuse the existing dynamic-tracepoint structured-logging descriptor format and code (this is upstream already):

[root@phoenix sched_signal_send]# pwd
/debug/tracing/events/sched/sched_signal_send

[root@phoenix sched_signal_send]# cat format
name: sched_signal_send
ID: 24
format:

	field:unsigned short common_type;		offset:0;	size:2;
	field:unsigned char common_flags;		offset:2;	size:1;
	field:unsigned char common_preempt_count;	offset:3;	size:1;
	field:int common_pid;				offset:4;	size:4;
	field:int common_tgid;				offset:8;	size:4;

	field:int sig;					offset:12;	size:4;
	field:char comm[TASK_COMM_LEN];			offset:16;	size:16;
	field:pid_t pid;				offset:32;	size:4;

print fmt: "sig: %d task %s:%d", REC->sig, REC->comm, REC->pid

These format descriptors enumerate fields, types and sizes, in a structured way that user-space tools can parse easily. (The binary records that come from the trace_pipe file follow this format description.)

3) /debug/tracing/objects/mm/pages/filter

This is the tracing filter that can be set based on the 'format' descriptor. So with the above (signal-send tracepoint) you can define such filter expressions:

  echo "(sig == 10 && comm == bash) || sig == 13" > filter

To restrict the 'scope' of the object collection along pretty much any key or combination of keys. (Or you can leave it as it is and dump all objects and do keying in user-space.)

[ Using in-kernel filtering is obviously faster that streaming it
out to user-space - but there might be details and types of visualization you want to do in user-space - so we dont want to restrict things here. ]

For the mm object collection tracepoint i could imagine such filter expressions:

  echo "type == shared && file == /sbin/init" > filter

To dump all shared pages that are mapped to /sbin/init.

4) /debug/tracing/objects/mm/pages/trace_pipe

The 'trace_pipe' file can be used to dump all objects in the collection, which match the filter ('all objects' by default). The record format is described in 'format'.

trace_pipe would be a reuse of the existing trace_pipe code: it is a modern, poll()-able, read()-able, splice()-able pipe abstraction.

5) /debug/tracing/objects/mm/pages/stats

The 'stats' file would be a reuse of the existing histogram code of the tracing code. We already make use of it for the branch tracers and for the workqueue tracer - it could be extended to be applicable to object collections as well.

The advantage there would be that there's no dumping at all - all the integration is done straight in the kernel. ( The 'filter' condition is listened to - increasing flexibility. The filter file could perhaps also act as a default histogram key. )

6) /debug/tracing/objects/mm/pages/events/

The 'events' directory offers links back to existing dynamic tracepoints that are under /debug/tracing/events/. This would serve as an additional coherent force that keeps dynamic tracepoints collected by subsystem and by object type as well. (Tools could make use of this information as well - without being aware of actual object semantics.)

There would be a number of other object collections we could enumerate:

tasks:

/debug/tracing/objects/sched/tasks/

active inodes known to the kernel:

/debug/tracing/objects/fs/inodes/

interrupts:

/debug/tracing/objects/hw/irqs/

etc.

These would use the same 'object collection' framework. Once done we can use it for many other thing too.

Note how organically integrated it all is with the tracing framework. You could start from an 'object view' to get an overview and then go towards a more dynamic view of specific object attributes (or specific objects), as you drill down on a specific problem you want to analyze.

How does this all sound to you?

Can you see any conceptual holes in the scheme, any use-case that /proc/kpageflags supports but the object collection approach does not?

Would you be interested in seeing something like this, if we tried to implement it in the tracing tree? The majority of the code already exists, we just need interest from the MM side and we have to hook it all up. (it is by no means trivial to do - but looks like a very exciting feature.)

Quoted 145 lines · Ingo Molnar

tent-Transfer-Encoding: quoted-printable
Status: RO
Content-Length: 5480
Lines: 161

Quoted 9 lines · Wu Fengguang

Quoted 3 lines

The above 'get object state' interface (which allows passive sampling) - integrated into the tracing framework - would serve that goal, agreed?

Agreed. That could in theory a good complement to dynamic tracings.

Then what will be the canonical form for all the 'get object state' interfaces - "object.attr=value", or whatever? [...]

Lemme outline what i'm thinking of.

I'd call the feature "object collection tracing", which would live in /debug/tracing, accessed via such files:

/debug/tracing/objects/mm/pages/
/debug/tracing/objects/mm/pages/format
/debug/tracing/objects/mm/pages/filter
/debug/tracing/objects/mm/pages/trace_pipe
/debug/tracing/objects/mm/pages/stats
/debug/tracing/objects/mm/pages/events/

here's the (proposed) semantics of those files:

1) /debug/tracing/objects/mm/pages/

There's a subsystem / object basic directory structure to make it easy and intuitive to find our way around there.

2) /debug/tracing/objects/mm/pages/format

the format file:

/debug/tracing/objects/mm/pages/format

Would reuse the existing dynamic-tracepoint structured-logging descriptor format and code (this is upstream already):

[root@phoenix sched_signal_send]# pwd
/debug/tracing/events/sched/sched_signal_send

[root@phoenix sched_signal_send]# cat format
name: sched_signal_send
ID: 24
format:

	field:unsigned short common_type;		offset:0;	size:2;
	field:unsigned char common_flags;		offset:2;	size:1;
	field:unsigned char common_preempt_count;	offset:3;	size:1;
	field:int common_pid;				offset:4;	size:4;
	field:int common_tgid;				offset:8;	size:4;

	field:int sig;					offset:12;	size:4;
	field:char comm[TASK_COMM_LEN];			offset:16;	size:16;
	field:pid_t pid;				offset:32;	size:4;

print fmt: "sig: %d task %s:%d", REC->sig, REC->comm, REC->pid

These format descriptors enumerate fields, types and sizes, in a structured way that user-space tools can parse easily. (The binary records that come from the trace_pipe file follow this format description.)

3) /debug/tracing/objects/mm/pages/filter

This is the tracing filter that can be set based on the 'format' descriptor. So with the above (signal-send tracepoint) you can define such filter expressions:

  echo "(sig == 10 && comm == bash) || sig == 13" > filter

To restrict the 'scope' of the object collection along pretty much any key or combination of keys. (Or you can leave it as it is and dump all objects and do keying in user-space.)

[ Using in-kernel filtering is obviously faster that streaming it
out to user-space - but there might be details and types of visualization you want to do in user-space - so we dont want to restrict things here. ]

For the mm object collection tracepoint i could imagine such filter expressions:

  echo "type == shared && file == /sbin/init" > filter

To dump all shared pages that are mapped to /sbin/init.

4) /debug/tracing/objects/mm/pages/trace_pipe

The 'trace_pipe' file can be used to dump all objects in the collection, which match the filter ('all objects' by default). The record format is described in 'format'.

trace_pipe would be a reuse of the existing trace_pipe code: it is a modern, poll()-able, read()-able, splice()-able pipe abstraction.

5) /debug/tracing/objects/mm/pages/stats

The 'stats' file would be a reuse of the existing histogram code of the tracing code. We already make use of it for the branch tracers and for the workqueue tracer - it could be extended to be applicable to object collections as well.

The advantage there would be that there's no dumping at all - all the integration is done straight in the kernel. ( The 'filter' condition is listened to - increasing flexibility. The filter file could perhaps also act as a default histogram key. )

6) /debug/tracing/objects/mm/pages/events/

The 'events' directory offers links back to existing dynamic tracepoints that are under /debug/tracing/events/. This would serve as an additional coherent force that keeps dynamic tracepoints collected by subsystem and by object type as well. (Tools could make use of this information as well - without being aware of actual object semantics.)

There would be a number of other object collections we could enumerate:

tasks:

/debug/tracing/objects/sched/tasks/

active inodes known to the kernel:

/debug/tracing/objects/fs/inodes/

interrupts:

/debug/tracing/objects/hw/irqs/

etc.

These would use the same 'object collection' framework. Once done we can use it for many other thing too.

Quoted 7 lines

Note how organically integrated it all is with the tracing framework. You could start from an 'object view' to get an overview and then go towards a more dynamic view of specific object attributes (or specific objects), as you drill down on a specific problem you want to analyze.

How does this all sound to you?

Great! I saw much opportunity to adapt the not yet submitted /proc/filecache interface to the proposed framework.

Its basic form is:

# ino size cached cached% refcnt state age accessed process dev file
[snip]

       320          1        4     100      1    D-     50443     1085 udevd           00:11(tmpfs)     /.udev/uevent_seqnum
    460725        123      124     100     35    --     50444     6795 touch           08:02(sda2)      /lib/libpthread-2.9.so
    460727         31       32     100     14    --     50444     2007 touch           08:02(sda2)      /lib/librt-2.9.so
    458865         97       80      82      1    --     50444       49 mount           08:02(sda2)      /lib/libdevmapper.so.1.02.1
    460090         15       16     100      1    --     50444       48 mount           08:02(sda2)      /lib/libuuid.so.1.2
    458866         46       48     100      1    --     50444       47 mount           08:02(sda2)      /lib/libblkid.so.1.0
    460732         43       44     100     69    --     50444     3581 rcS             08:02(sda2)      /lib/libnss_nis-2.9.so
    460739         87       88     100     73    --     50444     3597 rcS             08:02(sda2)      /lib/libnsl-2.9.so
    460726         31       32     100     69    --     50444     3581 rcS             08:02(sda2)      /lib/libnss_compat-2.9.so
    458804        250      252     100     11    --     50445     8175 rcS             08:02(sda2)      /lib/libncurses.so.5.6
    229540        780      752      96      3    --     50445     7594 init            08:02(sda2)      /bin/bash
    460735         15       16     100     89    --     50445    17581 init            08:02(sda2)      /lib/libdl-2.9.so
    460721       1344     1340      99    117    --     50445    48732 init            08:02(sda2)      /lib/libc-2.9.so
    458801        107      104      97     24    --     50445     3586 init            08:02(sda2)      /lib/libselinux.so.1
    671870         37       24      65      1    --     50446        1 swapper         08:02(sda2)      /sbin/init
       175          1    24412     100      1    --     50446        0 swapper         00:01(rootfs)    /dev/root

The patch basically does a traversal through one or more of the inode lists to produce the output:

        inode_in_use
        inode_unused
        sb->s_dirty
        sb->s_io
        sb->s_more_io
        sb->s_inodes

The filtering feature is a necessity for this interface - or it will take considerable time to do a full listing. It supports the following filters:

        { LS_OPT_DIRTY,         "dirty"         },
        { LS_OPT_CLEAN,         "clean"         },
        { LS_OPT_INUSE,         "inuse"         },
        { LS_OPT_EMPTY,         "empty"         },
        { LS_OPT_ALL,           "all"           },
        { LS_OPT_DEV,           "dev=%s"        },

There are two possible challenges for the conversion:

- One trick it does is to select different lists to traverse on different filter options. Will this be possible in the object tracing framework?

- The file name lookup(last field) is the performance killer. Is it possible to skip the file name lookup when the filter failed on the leading fields?

Will the object tracing interface allow such flexibilities? (Sorry I'm not yet familiar with the tracing framework.)

Quoted 3 lines

Can you see any conceptual holes in the scheme, any use-case that /proc/kpageflags supports but the object collection approach does not?

kpageflags is simply a big (perhaps sparse) binary array. I'd still prefer to retain its current form - the kernel patches and user space tools are all ready made, and I see no benefits in converting to the tracing framework.

Quoted 5 lines

Would you be interested in seeing something like this, if we tried to implement it in the tracing tree? The majority of the code already exists, we just need interest from the MM side and we have to hook it all up. (it is by no means trivial to do - but looks like a very exciting feature.)

Definitely! /proc/filecache has another 'page view':

        # head /proc/filecache
        # file /bin/bash
        # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback X:readahead P:private O:owner b:buffer d:dirty w:writeback
        # idx   len     state           refcnt
        0       1       RAMU________    4
        3       8       RAMU________    4
        12      1       RAMU________    4
        14      5       RAMU________    4
        20      7       RAMU________    4
        27      2       RAMU________    5
        29      1       RAMU________    4

Which is also a good candidate. However I still need to investigate whether it offers considerable margins over the mincore() syscall.

Thanks and Regards,
Fengguang

Quoted 7 lines · Wu Fengguang

On Tue, Apr 28, 2009 at 08:17:51PM +0800, Ingo Molnar wrote:

There are two possible challenges for the conversion:

- One trick it does is to select different lists to traverse on different filter options. Will this be possible in the object tracing framework?

Yeah, I guess.

Quoted 4 lines

- The file name lookup(last field) is the performance killer. Is it possible to skip the file name lookup when the filter failed on the leading fields?

objects collection lays on trace events where filters basically ignore a whole entry in case of non-matching. Not sure if we can easily only ignore one field.

But I guess we can do something about the performances...

Could you send us the (sob'ed) patch you made which implements this. I could try to adapt it to object collection.

Quoted 10 lines · Frederic Weisbecker

Quoted 7 lines · Wu Fengguang

On Tue, Apr 28, 2009 at 08:17:51PM +0800, Ingo Molnar wrote:

There are two possible challenges for the conversion:

- One trick it does is to select different lists to traverse on different filter options. Will this be possible in the object tracing framework?

Yeah, I guess.

Great.

Quoted 10 lines

Quoted 4 lines

- The file name lookup(last field) is the performance killer. Is it possible to skip the file name lookup when the filter failed on the leading fields?

objects collection lays on trace events where filters basically ignore a whole entry in case of non-matching. Not sure if we can easily only ignore one field.

But I guess we can do something about the performances...

OK, but it's not as important as the previous requirement, so it could be the last thing to work on :)

Quoted 2 lines

Could you send us the (sob'ed) patch you made which implements this. I could try to adapt it to object collection.

Attached for your reference. Be aware that I still have plans to change it in non trivial way, and there are ongoing works by Nick(on inode_lock) and Jens(on s_dirty) that can create merge conflicts. So basically it is not a right time to do the adaption.

However we can still do something to polish up the page object collection under /debug/tracing/objects/mm/pages/. For example, the timestamps and function name could be removed from the following list :)

# tracer: nop
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |

           <...>-3743  [001]  3035.649769: dump_pages: pfn=1 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176403: dump_pages: pfn=1 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176407: dump_pages: pfn=2 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176408: dump_pages: pfn=3 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176409: dump_pages: pfn=4 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176409: dump_pages: pfn=5 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176410: dump_pages: pfn=6 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176410: dump_pages: pfn=7 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176411: dump_pages: pfn=8 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176411: dump_pages: pfn=9 flags=400 count=1 mapcount=0 index=0                           
           <...>-3743  [001]  3044.176412: dump_pages: pfn=10 flags=400 count=1 mapcount=0 index=0                          

Thanks,
Fengguang

include/linux/mm.h +1 -0

@@ -27,6 +27,7 @@ extern unsigned long max_mapnr;
 extern unsigned long num_physpages;
 extern void * high_memory;
 extern int page_cluster;
+extern char * const zone_names[];
 
 #ifdef CONFIG_SYSCTL
 extern int sysctl_legacy_va_layout;

mm/page_alloc.c +1 -1

@@ -104,7 +104,7 @@ int sysctl_lowmem_reserve_ratio[MAX_NR_Z
 
 EXPORT_SYMBOL(totalram_pages);
 
-static char * const zone_names[MAX_NR_ZONES] = {
+char * const zone_names[MAX_NR_ZONES] = {
 #ifdef CONFIG_ZONE_DMA
 	 "DMA",
 #endif

fs/dcache.c +4 -1

@@ -1925,7 +1925,10 @@ char *__d_path(const struct path *path, 
 
 		if (dentry == root->dentry && vfsmnt == root->mnt)
 			break;
-		if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
+		if (unlikely(!vfsmnt)) {
+			if (IS_ROOT(dentry))
+				break;
+		} else if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
 			/* Global root? */
 			if (vfsmnt->mnt_parent == vfsmnt) {
 				goto global_root;

lib/radix-tree.c +0 -2

@@ -564,7 +564,6 @@ out:
 }
 EXPORT_SYMBOL(radix_tree_tag_clear);
 
-#ifndef __KERNEL__	/* Only the test harness uses this at present */
 /**
  * radix_tree_tag_get - get a tag on a radix tree node
  * @root:		radix tree root

@@ -627,7 +626,6 @@ int radix_tree_tag_get(struct radix_tree
 	}
 }
 EXPORT_SYMBOL(radix_tree_tag_get);
-#endif
 
 /**
  *	radix_tree_next_hole    -    find the next hole (not-present entry)

fs/inode.c +25 -1

@@ -84,6 +84,10 @@ static struct hlist_head *inode_hashtabl
  */
 DEFINE_SPINLOCK(inode_lock);
 
+EXPORT_SYMBOL(inode_in_use);
+EXPORT_SYMBOL(inode_unused);
+EXPORT_SYMBOL(inode_lock);
+
 /*
  * iprune_mutex provides exclusion between the kswapd or try_to_free_pages
  * icache shrinking path, and the umount path.  Without this exclusion,

@@ -110,6 +114,13 @@ static void wake_up_inode(struct inode *
 	wake_up_bit(&inode->i_state, __I_LOCK);
 }
 
+static inline void inode_created_by(struct inode *inode, struct task_struct *task)
+{
+#ifdef CONFIG_PROC_FILECACHE_EXTRAS
+	memcpy(inode->i_comm, task->comm, sizeof(task->comm));
+#endif
+}
+
 /**
  * inode_init_always - perform inode structure intialisation
  * @sb: superblock inode belongs to

@@ -147,7 +158,7 @@ struct inode *inode_init_always(struct s
 	inode->i_bdev = NULL;
 	inode->i_cdev = NULL;
 	inode->i_rdev = 0;
-	inode->dirtied_when = 0;
+	inode->dirtied_when = jiffies;
 
 	if (security_inode_alloc(inode))
 		goto out_free_inode;

@@ -188,6 +199,7 @@ struct inode *inode_init_always(struct s
 	}
 	inode->i_private = NULL;
 	inode->i_mapping = mapping;
+	inode_created_by(inode, current);
 
 	return inode;
 

@@ -276,6 +288,8 @@ void __iget(struct inode *inode)
 	inodes_stat.nr_unused--;
 }
 
+EXPORT_SYMBOL(__iget);
+
 /**
  * clear_inode - clear an inode
  * @inode: inode to clear

@@ -1459,6 +1473,16 @@ static void __wait_on_freeing_inode(stru
 	spin_lock(&inode_lock);
 }
 
+
+struct hlist_head * get_inode_hash_budget(unsigned long index)
+{
+       if (index >= (1 << i_hash_shift))
+               return NULL;
+
+       return inode_hashtable + index;
+}
+EXPORT_SYMBOL_GPL(get_inode_hash_budget);
+
 static __initdata unsigned long ihash_entries;
 static int __init set_ihash_entries(char *str)
 {

fs/super.c +3 -0

@@ -46,6 +46,9 @@
 LIST_HEAD(super_blocks);
 DEFINE_SPINLOCK(sb_lock);
 
+EXPORT_SYMBOL(super_blocks);
+EXPORT_SYMBOL(sb_lock);
+
 /**
  *	alloc_super	-	create new superblock
  *	@type:	filesystem type superblock should belong to

mm/vmscan.c +1 -0

@@ -262,6 +262,7 @@ unsigned long shrink_slab(unsigned long 
 	up_read(&shrinker_rwsem);
 	return ret;
 }
+EXPORT_SYMBOL(shrink_slab);
 
 /* Called without lock on whether page is mapped, so answer is unstable */
 static inline int page_mapping_inuse(struct page *page)

mm/swap_state.c +1 -0

@@ -45,6 +45,7 @@ struct address_space swapper_space = {
 	.i_mmap_nonlinear = LIST_HEAD_INIT(swapper_space.i_mmap_nonlinear),
 	.backing_dev_info = &swap_backing_dev_info,
 };
+EXPORT_SYMBOL_GPL(swapper_space);
 
 #define INC_CACHE_INFO(x)	do { swap_cache_info.x++; } while (0)
 

Documentation/filesystems/proc.txt +83 -0

@@ -260,6 +260,7 @@ Table 1-4: Kernel info in /proc
  driver	     Various drivers grouped here, currently rtc (2.4)
  execdomains Execdomains, related to security			(2.4)
  fb	     Frame Buffer devices				(2.4)
+ filecache   Query/drop in-memory file cache
  fs	     File system parameters, currently nfs/exports	(2.4)
  ide         Directory containing info about the IDE subsystem 
  interrupts  Interrupt usage                                   

@@ -450,6 +451,88 @@ varies by architecture and compile optio
 
 > cat /proc/meminfo
 
+..............................................................................
+
+filecache:
+
+Provides access to the in-memory file cache.
+
+To list an index of all cached files:
+
+    echo ls > /proc/filecache
+    cat /proc/filecache
+
+The output looks like:
+
+    # filecache 1.0
+    #      ino       size   cached cached%  state   refcnt  dev             file
+       1026334         91       92    100   --      66      03:02(hda2)     /lib/ld-2.3.6.so
+        233608       1242      972     78   --      66      03:02(hda2)     /lib/tls/libc-2.3.6.so
+         65203        651      476     73   --      1       03:02(hda2)     /bin/bash
+       1026445        261      160     61   --      10      03:02(hda2)     /lib/libncurses.so.5.5
+        235427         10       12    100   --      44      03:02(hda2)     /lib/tls/libdl-2.3.6.so
+
+FIELD	INTRO
+---------------------------------------------------------------------------
+ino	inode number
+size	inode size in KB
+cached	cached size in KB
+cached%	percent of file data cached
+state1	'-' clean; 'd' metadata dirty; 'D' data dirty
+state2	'-' unlocked; 'L' locked, normally indicates file being written out
+refcnt	file reference count, it's an in-kernel one, not exactly open count
+dev	major:minor numbers in hex, followed by a descriptive device name
+file	file path _inside_ the filesystem. There are several special names:
+	'(noname)':	the file name is not available
+	'(03:02)':	the file is a block device file of major:minor
+	'...(deleted)': the named file has been deleted from the disk
+
+To list the cached pages of a perticular file:
+
+    echo /bin/bash > /proc/filecache
+    cat /proc/filecache
+
+    # file /bin/bash
+    # flags R:referenced A:active U:uptodate D:dirty W:writeback M:mmap
+    # idx   len     state   refcnt
+    0       36      RAU__M  3
+    36      1       RAU__M  2
+    37      8       RAU__M  3
+    45      2       RAU___  1
+    47      6       RAU__M  3
+    53      3       RAU__M  2
+    56      2       RAU__M  3
+
+FIELD	INTRO
+----------------------------------------------------------------------------
+idx	page index
+len	number of pages which are cached and share the same state
+state	page state of the flags listed in line two
+refcnt	page reference count
+
+Careful users may notice that the file name to be queried is remembered between
+commands. Internally, the module has a global variable to store the file name
+parameter, so that it can be inherited by newly opened /proc/filecache file.
+However it can lead to interference for multiple queriers. The solution here
+is to obey a rule: only root can interactively change the file name parameter;
+normal users must go for scripts to access the interface. Scripts should do it
+by following the code example below:
+
+    filecache = open("/proc/filecache", "rw");
+    # avoid polluting the global parameter filename
+    filecache.write("set private");
+
+To instruct the kernel to drop clean caches, dentries and inodes from memory,
+causing that memory to become free:
+
+    # drop clean file data cache (i.e. file backed pagecache)
+    echo drop pagecache > /proc/filecache
+
+    # drop clean file metadata cache (i.e. dentries and inodes)
+    echo drop slabcache > /proc/filecache
+
+Note that the drop commands are non-destructive operations and dirty objects
+are not freeable, the user should run `sync' first.
 
 MemTotal:     16344972 kB
 MemFree:      13634064 kB

fs/proc/filecache.c new file +1045 -0

@@ -0,0 +1,1045 @@
+/*
+ * fs/proc/filecache.c
+ *
+ * Copyright (C) 2006, 2007 Fengguang Wu <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/fs.h>
+#include <linux/mm.h>
+#include <linux/radix-tree.h>
+#include <linux/page-flags.h>
+#include <linux/pagevec.h>
+#include <linux/pagemap.h>
+#include <linux/vmalloc.h>
+#include <linux/writeback.h>
+#include <linux/buffer_head.h>
+#include <linux/parser.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include <linux/file.h>
+#include <linux/namei.h>
+#include <linux/module.h>
+#include <asm/uaccess.h>
+
+/*
+ * Increase minor version when new columns are added;
+ * Increase major version when existing columns are changed.
+ */
+#define FILECACHE_VERSION	"1.0"
+
+/* Internal buffer sizes. The larger the more effcient. */
+#define SBUF_SIZE	(128<<10)
+#define IWIN_PAGE_ORDER	3
+#define IWIN_SIZE	((PAGE_SIZE<<IWIN_PAGE_ORDER) / sizeof(struct inode *))
+
+/*
+ * Session management.
+ *
+ * Each opened /proc/filecache file is assiocated with a session object.
+ * Also there is a global_session that maintains status across open()/close()
+ * (i.e. the lifetime of an opened file), so that a casual user can query the
+ * filecache via _multiple_ simple shell commands like
+ * 'echo cat /bin/bash > /proc/filecache; cat /proc/filecache'.
+ *
+ * session.query_file is the file whose cache info is to be queried.
+ * Its value determines what we get on read():
+ * 	- NULL: ii_*() called to show the inode index
+ * 	- filp: pg_*() called to show the page groups of a filp
+ *
+ * session.query_file is
+ * 	- cloned from global_session.query_file on open();
+ * 	- updated on write("cat filename");
+ * 	  note that the new file will also be saved in global_session.query_file if
+ * 	  session.private_session is false.
+ */
+
+struct session {
+	/* options */
+	int		private_session;
+	unsigned long	ls_options;
+	dev_t		ls_dev;
+
+	/* parameters */
+	struct file	*query_file;
+
+	/* seqfile pos */
+	pgoff_t		start_offset;
+	pgoff_t		next_offset;
+
+	/* inode at last pos */
+	struct {
+		unsigned long pos;
+		unsigned long state;
+		struct inode *inode;
+		struct inode *pinned_inode;
+	} ipos;
+
+	/* inode window */
+	struct {
+		unsigned long cursor;
+		unsigned long origin;
+		unsigned long size;
+		struct inode **inodes;
+	} iwin;
+};
+
+static struct session global_session;
+
+/*
+ * Session address is stored in proc_file->f_ra.start:
+ * we assume that there will be no readahead for proc_file.
+ */
+static struct session *get_session(struct file *proc_file)
+{
+	return (struct session *)proc_file->f_ra.start;
+}
+
+static void set_session(struct file *proc_file, struct session *s)
+{
+	BUG_ON(proc_file->f_ra.start);
+	proc_file->f_ra.start = (unsigned long)s;
+}
+
+static void update_global_file(struct session *s)
+{
+	if (s->private_session)
+		return;
+
+	if (global_session.query_file)
+		fput(global_session.query_file);
+
+	global_session.query_file = s->query_file;
+
+	if (global_session.query_file)
+		get_file(global_session.query_file);
+}
+
+/*
+ * Cases of the name:
+ * 1) NULL                (new session)
+ * 	s->query_file = global_session.query_file = 0;
+ * 2) ""                  (ls/la)
+ * 	s->query_file = global_session.query_file;
+ * 3) a regular file name (cat newfile)
+ * 	s->query_file = global_session.query_file = newfile;
+ */
+static int session_update_file(struct session *s, char *name)
+{
+	static DEFINE_MUTEX(mutex); /* protects global_session.query_file */
+	int err = 0;
+
+	mutex_lock(&mutex);
+
+	/*
+	 * We are to quit, or to list the cached files.
+	 * Reset *.query_file.
+	 */
+	if (!name) {
+		if (s->query_file) {
+			fput(s->query_file);
+			s->query_file = NULL;
+		}
+		update_global_file(s);
+		goto out;
+	}
+
+	/*
+	 * This is a new session.
+	 * Inherit options/parameters from global ones.
+	 */
+	if (name[0] == '\0') {
+		*s = global_session;
+		if (s->query_file)
+			get_file(s->query_file);
+		goto out;
+	}
+
+	/*
+	 * Open the named file.
+	 */
+	if (s->query_file)
+		fput(s->query_file);
+	s->query_file = filp_open(name, O_RDONLY|O_LARGEFILE, 0);
+	if (IS_ERR(s->query_file)) {
+		err = PTR_ERR(s->query_file);
+		s->query_file = NULL;
+	} else
+		update_global_file(s);
+
+out:
+	mutex_unlock(&mutex);
+
+	return err;
+}
+
+static struct session *session_create(void)
+{
+	struct session *s;
+	int err = 0;
+
+	s = kmalloc(sizeof(*s), GFP_KERNEL);
+	if (s)
+		err = session_update_file(s, "");
+	else
+		err = -ENOMEM;
+
+	return err ? ERR_PTR(err) : s;
+}
+
+static void session_release(struct session *s)
+{
+	if (s->ipos.pinned_inode)
+		iput(s->ipos.pinned_inode);
+	if (s->query_file)
+		fput(s->query_file);
+	kfree(s);
+}
+
+
+/*
+ * Listing of cached files.
+ *
+ * Usage:
+ * 		echo > /proc/filecache  # enter listing mode
+ * 		cat /proc/filecache     # get the file listing
+ */
+
+/* code style borrowed from ib_srp.c */
+enum {
+	LS_OPT_ERR	=	0,
+	LS_OPT_DIRTY	=	1 << 0,
+	LS_OPT_CLEAN	=	1 << 1,
+	LS_OPT_INUSE	=	1 << 2,
+	LS_OPT_EMPTY	=	1 << 3,
+	LS_OPT_ALL	=	1 << 4,
+	LS_OPT_DEV	=	1 << 5,
+};
+
+static match_table_t ls_opt_tokens = {
+	{ LS_OPT_DIRTY,		"dirty" 	},
+	{ LS_OPT_CLEAN,		"clean" 	},
+	{ LS_OPT_INUSE,		"inuse" 	},
+	{ LS_OPT_EMPTY,		"empty"		},
+	{ LS_OPT_ALL,		"all" 		},
+	{ LS_OPT_DEV,		"dev=%s"	},
+	{ LS_OPT_ERR,		NULL 		}
+};
+
+static int ls_parse_options(const char *buf, struct session *s)
+{
+	substring_t args[MAX_OPT_ARGS];
+	char *options, *sep_opt;
+	char *p;
+	int token;
+	int ret = 0;
+
+	if (!buf)
+		return 0;
+	options = kstrdup(buf, GFP_KERNEL);
+	if (!options)
+		return -ENOMEM;
+
+	s->ls_options = 0;
+	sep_opt = options;
+	while ((p = strsep(&sep_opt, " ")) != NULL) {
+		if (!*p)
+			continue;
+
+		token = match_token(p, ls_opt_tokens, args);
+
+		switch (token) {
+		case LS_OPT_DIRTY:
+		case LS_OPT_CLEAN:
+		case LS_OPT_INUSE:
+		case LS_OPT_EMPTY:
+		case LS_OPT_ALL:
+			s->ls_options |= token;
+			break;
+		case LS_OPT_DEV:
+			p = match_strdup(args);
+			if (!p) {
+				ret = -ENOMEM;
+				goto out;
+			}
+			if (*p == '/') {
+				struct kstat stat;
+				struct nameidata nd;
+				ret = path_lookup(p, LOOKUP_FOLLOW, &nd);
+				if (!ret)
+					ret = vfs_getattr(nd.path.mnt,
+							  nd.path.dentry, &stat);
+				if (!ret)
+					s->ls_dev = stat.rdev;
+			} else
+				s->ls_dev = simple_strtoul(p, NULL, 0);
+			/* printk("%lx %s\n", (long)s->ls_dev, p); */
+			kfree(p);
+			break;
+
+		default:
+			printk(KERN_WARNING "unknown parameter or missing value "
+			       "'%s' in ls command\n", p);
+			ret = -EINVAL;
+			goto out;
+		}
+	}
+
+out:
+	kfree(options);
+	return ret;
+}
+
+/*
+ * Add possible filters here.
+ * No permission check: we cannot verify the path's permission anyway.
+ * We simply demand root previledge for accessing /proc/filecache.
+ */
+static int may_show_inode(struct session *s, struct inode *inode)
+{
+	if (!atomic_read(&inode->i_count))
+		return 0;
+	if (inode->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+		return 0;
+	if (!inode->i_mapping)
+		return 0;
+
+	if (s->ls_dev && s->ls_dev != inode->i_sb->s_dev)
+		return 0;
+
+	if (s->ls_options & LS_OPT_ALL)
+		return 1;
+
+	if (!(s->ls_options & LS_OPT_EMPTY) && !inode->i_mapping->nrpages)
+		return 0;
+
+	if ((s->ls_options & LS_OPT_DIRTY) && !(inode->i_state & I_DIRTY))
+		return 0;
+
+	if ((s->ls_options & LS_OPT_CLEAN) && (inode->i_state & I_DIRTY))
+		return 0;
+
+	if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
+	      S_ISLNK(inode->i_mode) || S_ISBLK(inode->i_mode)))
+		return 0;
+
+	return 1;
+}
+
+/*
+ * Full: there are more data following.
+ */
+static int iwin_full(struct session *s)
+{
+	return !s->iwin.cursor ||
+		s->iwin.cursor > s->iwin.origin + s->iwin.size;
+}
+
+static int iwin_push(struct session *s, struct inode *inode)
+{
+	if (!may_show_inode(s, inode))
+		return 0;
+
+	s->iwin.cursor++;
+
+	if (s->iwin.size >= IWIN_SIZE)
+		return 1;
+
+	if (s->iwin.cursor > s->iwin.origin)
+		s->iwin.inodes[s->iwin.size++] = inode;
+	return 0;
+}
+
+/*
+ * Travease the inode lists in order - newest first.
+ * And fill @s->iwin.inodes with inodes positioned in [@pos, @pos+IWIN_SIZE).
+ */
+static int iwin_fill(struct session *s, unsigned long pos)
+{
+	struct inode *inode;
+	struct super_block *sb;
+
+	s->iwin.origin = pos;
+	s->iwin.cursor = 0;
+	s->iwin.size = 0;
+
+	/*
+	 * We have a cursor inode, clean and expected to be unchanged.
+	 */
+	if (s->ipos.inode && pos >= s->ipos.pos &&
+			!(s->ipos.state & I_DIRTY) &&
+			s->ipos.state == s->ipos.inode->i_state) {
+		inode = s->ipos.inode;
+		s->iwin.cursor = s->ipos.pos;
+		goto continue_from_saved;
+	}
+
+	if (s->ls_options & LS_OPT_CLEAN)
+		goto clean_inodes;
+
+	spin_lock(&sb_lock);
+	list_for_each_entry(sb, &super_blocks, s_list) {
+		if (s->ls_dev && s->ls_dev != sb->s_dev)
+			continue;
+
+		list_for_each_entry(inode, &sb->s_dirty, i_list) {
+			if (iwin_push(s, inode))
+				goto out_full_unlock;
+		}
+		list_for_each_entry(inode, &sb->s_io, i_list) {
+			if (iwin_push(s, inode))
+				goto out_full_unlock;
+		}
+	}
+	spin_unlock(&sb_lock);
+
+clean_inodes:
+	list_for_each_entry(inode, &inode_in_use, i_list) {
+		if (iwin_push(s, inode))
+			goto out_full;
+continue_from_saved:
+		;
+	}
+
+	if (s->ls_options & LS_OPT_INUSE)
+		return 0;
+
+	list_for_each_entry(inode, &inode_unused, i_list) {
+		if (iwin_push(s, inode))
+			goto out_full;
+	}
+
+	return 0;
+
+out_full_unlock:
+	spin_unlock(&sb_lock);
+out_full:
+	return 1;
+}
+
+static struct inode *iwin_inode(struct session *s, unsigned long pos)
+{
+	if ((iwin_full(s) && pos >= s->iwin.origin + s->iwin.size)
+			  || pos < s->iwin.origin)
+		iwin_fill(s, pos);
+
+	if (pos >= s->iwin.cursor)
+		return NULL;
+
+	s->ipos.pos = pos;
+	s->ipos.inode = s->iwin.inodes[pos - s->iwin.origin];
+	BUG_ON(!s->ipos.inode);
+	return s->ipos.inode;
+}
+
+static void show_inode(struct seq_file *m, struct inode *inode)
+{
+	char state[] = "--"; /* dirty, locked */
+	struct dentry *dentry;
+	loff_t size = i_size_read(inode);
+	unsigned long nrpages;
+	int percent;
+	int refcnt;
+	int shift;
+
+	if (!size)
+		size++;
+
+	if (inode->i_mapping)
+		nrpages = inode->i_mapping->nrpages;
+	else {
+		nrpages = 0;
+		WARN_ON(1);
+	}
+
+	for (shift = 0; (size >> shift) > ULONG_MAX / 128; shift += 12)
+		;
+	percent = min(100UL, (((100 * nrpages) >> shift) << PAGE_CACHE_SHIFT) /
+						(unsigned long)(size >> shift));
+
+	if (inode->i_state & (I_DIRTY_DATASYNC|I_DIRTY_PAGES))
+		state[0] = 'D';
+	else if (inode->i_state & I_DIRTY_SYNC)
+		state[0] = 'd';
+
+	if (inode->i_state & I_LOCK)
+		state[0] = 'L';
+
+	refcnt = 0;
+	list_for_each_entry(dentry, &inode->i_dentry, d_alias) {
+		refcnt += atomic_read(&dentry->d_count);
+	}
+
+	seq_printf(m, "%10lu %10llu %8lu %7d ",
+			inode->i_ino,
+			DIV_ROUND_UP(size, 1024),
+			nrpages << (PAGE_CACHE_SHIFT - 10),
+			percent);
+
+	seq_printf(m, "%6d %5s %9lu ",
+			refcnt,
+			state,
+			(jiffies - inode->dirtied_when) / HZ);
+
+#ifdef CONFIG_PROC_FILECACHE_EXTRAS
+	seq_printf(m, "%8u %-16s",
+			inode->i_access_count,
+			inode->i_comm);
+#endif
+
+	seq_printf(m, "%02x:%02x(%s)\t",
+			MAJOR(inode->i_sb->s_dev),
+			MINOR(inode->i_sb->s_dev),
+			inode->i_sb->s_id);
+
+	if (list_empty(&inode->i_dentry)) {
+		if (!atomic_read(&inode->i_count))
+			seq_puts(m, "(noname)\n");
+		else
+			seq_printf(m, "(%02x:%02x)\n",
+					imajor(inode), iminor(inode));
+	} else {
+		struct path path = {
+			.mnt = NULL,
+			.dentry = list_entry(inode->i_dentry.next,
+					     struct dentry, d_alias)
+		};
+
+		seq_path(m, &path, " \t\n\\");
+		seq_putc(m, '\n');
+	}
+}
+
+static int ii_show(struct seq_file *m, void *v)
+{
+	unsigned long index = *(loff_t *) v;
+	struct session *s = m->private;
+        struct inode *inode;
+
+	if (index == 0) {
+		seq_puts(m, "# filecache " FILECACHE_VERSION "\n");
+		seq_puts(m, "#      ino       size   cached cached% "
+				"refcnt state       age "
+#ifdef CONFIG_PROC_FILECACHE_EXTRAS
+				"accessed  process         "
+#endif
+				"dev\t\tfile\n");
+	}
+
+        inode = iwin_inode(s,index);
+	show_inode(m, inode);
+
+	return 0;
+}
+
+static void *ii_start(struct seq_file *m, loff_t *pos)
+{
+	struct session *s = m->private;
+
+	s->iwin.size = 0;
+	s->iwin.inodes = (struct inode **)
+				__get_free_pages( GFP_KERNEL, IWIN_PAGE_ORDER);
+	if (!s->iwin.inodes)
+		return NULL;
+
+	spin_lock(&inode_lock);
+
+	return iwin_inode(s, *pos) ? pos : NULL;
+}
+
+static void *ii_next(struct seq_file *m, void *v, loff_t *pos)
+{
+	struct session *s = m->private;
+
+	(*pos)++;
+	return iwin_inode(s, *pos) ? pos : NULL;
+}
+
+static void ii_stop(struct seq_file *m, void *v)
+{
+	struct session *s = m->private;
+	struct inode *inode = s->ipos.inode;
+
+	if (!s->iwin.inodes)
+		return;
+
+	if (inode) {
+		__iget(inode);
+		s->ipos.state = inode->i_state;
+	}
+	spin_unlock(&inode_lock);
+
+	free_pages((unsigned long) s->iwin.inodes, IWIN_PAGE_ORDER);
+	if (s->ipos.pinned_inode)
+		iput(s->ipos.pinned_inode);
+	s->ipos.pinned_inode = inode;
+}
+
+/*
+ * Listing of cached page ranges of a file.
+ *
+ * Usage:
+ * 		echo 'file name' > /proc/filecache
+ * 		cat /proc/filecache
+ */
+
+unsigned long page_mask;
+#define PG_MMAP		PG_lru		/* reuse any non-relevant flag */
+#define PG_BUFFER	PG_swapcache	/* ditto */
+#define PG_DIRTY	PG_error	/* ditto */
+#define PG_WRITEBACK	PG_buddy	/* ditto */
+
+/*
+ * Page state names, prefixed by their abbreviations.
+ */
+struct {
+	unsigned long	mask;
+	const char     *name;
+	int		faked;
+} page_flag [] = {
+	{1 << PG_referenced,	"R:referenced",	0},
+	{1 << PG_active,	"A:active",	0},
+	{1 << PG_MMAP,		"M:mmap",	1},
+
+	{1 << PG_uptodate,	"U:uptodate",	0},
+	{1 << PG_dirty,		"D:dirty",	0},
+	{1 << PG_writeback,	"W:writeback",	0},
+	{1 << PG_reclaim,	"X:readahead",	0},
+
+	{1 << PG_private,	"P:private",	0},
+	{1 << PG_owner_priv_1,	"O:owner",	0},
+
+	{1 << PG_BUFFER,	"b:buffer",	1},
+	{1 << PG_DIRTY,		"d:dirty",	1},
+	{1 << PG_WRITEBACK,	"w:writeback",	1},
+};
+
+static unsigned long page_flags(struct page* page)
+{
+	unsigned long flags;
+	struct address_space *mapping = page_mapping(page);
+
+	flags = page->flags & page_mask;
+
+	if (page_mapped(page))
+		flags |= (1 << PG_MMAP);
+
+	if (page_has_buffers(page))
+		flags |= (1 << PG_BUFFER);
+
+	if (mapping) {
+		if (radix_tree_tag_get(&mapping->page_tree,
+					page_index(page),
+					PAGECACHE_TAG_WRITEBACK))
+			flags |= (1 << PG_WRITEBACK);
+
+		if (radix_tree_tag_get(&mapping->page_tree,
+					page_index(page),
+					PAGECACHE_TAG_DIRTY))
+			flags |= (1 << PG_DIRTY);
+	}
+
+	return flags;
+}
+
+static int pages_similiar(struct page* page0, struct page* page)
+{
+	if (page_count(page0) != page_count(page))
+		return 0;
+
+	if (page_flags(page0) != page_flags(page))
+		return 0;
+
+	return 1;
+}
+
+static void show_range(struct seq_file *m, struct page* page, unsigned long len)
+{
+	int i;
+	unsigned long flags;
+
+	if (!m || !page)
+		return;
+
+	seq_printf(m, "%lu\t%lu\t", page->index, len);
+
+	flags = page_flags(page);
+	for (i = 0; i < ARRAY_SIZE(page_flag); i++)
+		seq_putc(m, (flags & page_flag[i].mask) ?
+					page_flag[i].name[0] : '_');
+
+	seq_printf(m, "\t%d\n", page_count(page));
+}
+
+#define BATCH_LINES	100
+static pgoff_t show_file_cache(struct seq_file *m,
+				struct address_space *mapping, pgoff_t start)
+{
+	int i;
+	int lines = 0;
+	pgoff_t len = 0;
+	struct pagevec pvec;
+	struct page *page;
+	struct page *page0 = NULL;
+
+	for (;;) {
+		pagevec_init(&pvec, 0);
+		pvec.nr = radix_tree_gang_lookup(&mapping->page_tree,
+				(void **)pvec.pages, start + len, PAGEVEC_SIZE);
+
+		if (pvec.nr == 0) {
+			show_range(m, page0, len);
+			start = ULONG_MAX;
+			goto out;
+		}
+
+		if (!page0)
+			page0 = pvec.pages[0];
+
+		for (i = 0; i < pvec.nr; i++) {
+			page = pvec.pages[i];
+
+			if (page->index == start + len &&
+					pages_similiar(page0, page))
+				len++;
+			else {
+				show_range(m, page0, len);
+				page0 = page;
+				start = page->index;
+				len = 1;
+				if (++lines > BATCH_LINES)
+					goto out;
+			}
+		}
+	}
+
+out:
+	return start;
+}
+
+static int pg_show(struct seq_file *m, void *v)
+{
+	struct session *s = m->private;
+	struct file *file = s->query_file;
+	pgoff_t offset;
+
+	if (!file)
+		return ii_show(m, v);
+
+	offset = *(loff_t *) v;
+
+	if (!offset) { /* print header */
+		int i;
+
+		seq_puts(m, "# file ");
+		seq_path(m, &file->f_path, " \t\n\\");
+
+		seq_puts(m, "\n# flags");
+		for (i = 0; i < ARRAY_SIZE(page_flag); i++)
+			seq_printf(m, " %s", page_flag[i].name);
+
+		seq_puts(m, "\n# idx\tlen\tstate\t\trefcnt\n");
+	}
+
+	s->start_offset = offset;
+	s->next_offset = show_file_cache(m, file->f_mapping, offset);
+
+	return 0;
+}
+
+static void *file_pos(struct file *file, loff_t *pos)
+{
+	loff_t size = i_size_read(file->f_mapping->host);
+	pgoff_t end = DIV_ROUND_UP(size, PAGE_CACHE_SIZE);
+	pgoff_t offset = *pos;
+
+	return offset < end ? pos : NULL;
+}
+
+static void *pg_start(struct seq_file *m, loff_t *pos)
+{
+	struct session *s = m->private;
+	struct file *file = s->query_file;
+	pgoff_t offset = *pos;
+
+	if (!file)
+		return ii_start(m, pos);
+
+	rcu_read_lock();
+
+	if (offset - s->start_offset == 1)
+		*pos = s->next_offset;
+	return file_pos(file, pos);
+}
+
+static void *pg_next(struct seq_file *m, void *v, loff_t *pos)
+{
+	struct session *s = m->private;
+	struct file *file = s->query_file;
+
+	if (!file)
+		return ii_next(m, v, pos);
+
+	*pos = s->next_offset;
+	return file_pos(file, pos);
+}
+
+static void pg_stop(struct seq_file *m, void *v)
+{
+	struct session *s = m->private;
+	struct file *file = s->query_file;
+
+	if (!file)
+		return ii_stop(m, v);
+
+	rcu_read_unlock();
+}
+
+struct seq_operations seq_filecache_op = {
+	.start	= pg_start,
+	.next	= pg_next,
+	.stop	= pg_stop,
+	.show	= pg_show,
+};
+
+/*
+ * Implement the manual drop-all-pagecache function
+ */
+
+#define MAX_INODES	(PAGE_SIZE / sizeof(struct inode *))
+static int drop_pagecache(void)
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct inode *inode;
+	struct inode **inodes;
+	unsigned long i, j, k;
+	int err = 0;
+
+	inodes = (struct inode **)__get_free_pages(GFP_KERNEL, IWIN_PAGE_ORDER);
+	if (!inodes)
+		return -ENOMEM;
+
+	for (i = 0; (head = get_inode_hash_budget(i)); i++) {
+		if (hlist_empty(head))
+			continue;
+
+		j = 0;
+		cond_resched();
+
+		/*
+		 * Grab some inodes.
+		 */
+		spin_lock(&inode_lock);
+		hlist_for_each (node, head) {
+			inode = hlist_entry(node, struct inode, i_hash);
+			if (!atomic_read(&inode->i_count))
+				continue;
+			if (inode->i_state & (I_FREEING|I_CLEAR|I_WILL_FREE))
+				continue;
+			if (!inode->i_mapping || !inode->i_mapping->nrpages)
+				continue;
+			__iget(inode);
+			inodes[j++] = inode;
+			if (j >= MAX_INODES)
+				break;
+		}
+		spin_unlock(&inode_lock);
+
+		/*
+		 * Free clean pages.
+		 */
+		for (k = 0; k < j; k++) {
+			inode = inodes[k];
+			invalidate_mapping_pages(inode->i_mapping, 0, ~1);
+			iput(inode);
+		}
+
+		/*
+		 * Simply ignore the remaining inodes.
+		 */
+		if (j >= MAX_INODES && !err) {
+			printk(KERN_WARNING
+				"Too many collides in inode hash table.\n"
+				"Pls boot with a larger ihash_entries=XXX.\n");
+			err = -EAGAIN;
+		}
+	}
+
+	free_pages((unsigned long) inodes, IWIN_PAGE_ORDER);
+	return err;
+}
+
+static void drop_slabcache(void)
+{
+	int nr_objects;
+
+	do {
+		nr_objects = shrink_slab(1000, GFP_KERNEL, 1000);
+	} while (nr_objects > 10);
+}
+
+/*
+ * Proc file operations.
+ */
+
+static int filecache_open(struct inode *inode, struct file *proc_file)
+{
+	struct seq_file *m;
+	struct session *s;
+	unsigned size;
+	char *buf = 0;
+	int ret;
+
+	if (!try_module_get(THIS_MODULE))
+		return -ENOENT;
+
+	s = session_create();
+	if (IS_ERR(s)) {
+		ret = PTR_ERR(s);
+		goto out;
+	}
+	set_session(proc_file, s);
+
+	size = SBUF_SIZE;
+	buf = kmalloc(size, GFP_KERNEL);
+	if (!buf) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	ret = seq_open(proc_file, &seq_filecache_op);
+	if (!ret) {
+		m = proc_file->private_data;
+		m->private = s;
+		m->buf = buf;
+		m->size = size;
+	}
+
+out:
+	if (ret) {
+		kfree(s);
+		kfree(buf);
+		module_put(THIS_MODULE);
+	}
+	return ret;
+}
+
+static int filecache_release(struct inode *inode, struct file *proc_file)
+{
+	struct session *s = get_session(proc_file);
+	int ret;
+
+	session_release(s);
+	ret = seq_release(inode, proc_file);
+	module_put(THIS_MODULE);
+	return ret;
+}
+
+ssize_t filecache_write(struct file *proc_file, const char __user * buffer,
+			size_t count, loff_t *ppos)
+{
+	struct session *s;
+	char *name;
+	int err = 0;
+
+	if (count >= PATH_MAX + 5)
+		return -ENAMETOOLONG;
+
+	name = kmalloc(count+1, GFP_KERNEL);
+	if (!name)
+		return -ENOMEM;
+
+	if (copy_from_user(name, buffer, count)) {
+		err = -EFAULT;
+		goto out;
+	}
+
+	/* strip the optional newline */
+	if (count && name[count-1] == '\n')
+		name[count-1] = '\0';
+	else
+		name[count] = '\0';
+
+	s = get_session(proc_file);
+	if (!strcmp(name, "set private")) {
+		s->private_session = 1;
+		goto out;
+	}
+
+	if (!strncmp(name, "cat ", 4)) {
+		err = session_update_file(s, name+4);
+		goto out;
+	}
+
+	if (!strncmp(name, "ls", 2)) {
+		err = session_update_file(s, NULL);
+		if (!err)
+			err = ls_parse_options(name+2, s);
+		if (!err && !s->private_session) {
+			global_session.ls_dev = s->ls_dev;
+			global_session.ls_options = s->ls_options;
+		}
+		goto out;
+	}
+
+	if (!strncmp(name, "drop pagecache", 14)) {
+		err = drop_pagecache();
+		goto out;
+	}
+
+	if (!strncmp(name, "drop slabcache", 14)) {
+		drop_slabcache();
+		goto out;
+	}
+
+	/* err = -EINVAL; */
+	err = session_update_file(s, name);
+
+out:
+	kfree(name);
+
+	return err ? err : count;
+}
+
+static struct file_operations proc_filecache_fops = {
+	.owner		= THIS_MODULE,
+	.open		= filecache_open,
+	.release	= filecache_release,
+	.write		= filecache_write,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+};
+
+
+static __init int filecache_init(void)
+{
+	int i;
+	struct proc_dir_entry *entry;
+
+	entry = create_proc_entry("filecache", 0600, NULL);
+	if (entry)
+		entry->proc_fops = &proc_filecache_fops;
+
+	for (page_mask = i = 0; i < ARRAY_SIZE(page_flag); i++)
+		if (!page_flag[i].faked)
+			page_mask |= page_flag[i].mask;
+
+	return 0;
+}
+
+static void filecache_exit(void)
+{
+	remove_proc_entry("filecache", NULL);
+	if (global_session.query_file)
+		fput(global_session.query_file);
+}
+
+MODULE_AUTHOR("Fengguang Wu <[email protected]>");
+MODULE_LICENSE("GPL");
+
+module_init(filecache_init);
+module_exit(filecache_exit);

include/linux/fs.h +13 -0

@@ -775,6 +775,11 @@ struct inode {
 	void			*i_security;
 #endif
 	void			*i_private; /* fs or device private pointer */
+
+#ifdef CONFIG_PROC_FILECACHE_EXTRAS
+	unsigned int		i_access_count;	/* opened how many times? */
+	char			i_comm[16];	/* opened first by which app? */
+#endif
 };
 
 /*

@@ -860,6 +865,13 @@ static inline unsigned imajor(const stru
 	return MAJOR(inode->i_rdev);
 }
 
+static inline void inode_accessed(struct inode *inode)
+{
+#ifdef CONFIG_PROC_FILECACHE_EXTRAS
+	inode->i_access_count++;
+#endif
+}
+
 extern struct block_device *I_BDEV(struct inode *inode);
 
 struct fown_struct {

@@ -2171,6 +2183,7 @@ extern void remove_inode_hash(struct ino
 static inline void insert_inode_hash(struct inode *inode) {
 	__insert_inode_hash(inode, inode->i_ino);
 }
+struct hlist_head * get_inode_hash_budget(unsigned long index);
 
 extern struct file * get_empty_filp(void);
 extern void file_move(struct file *f, struct list_head *list);

fs/open.c +1 -0

@@ -842,6 +842,7 @@ static struct file *__dentry_open(struct
 			goto cleanup_all;
 	}
 
+	inode_accessed(inode);
 	f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC);
 
 	file_ra_state_init(&f->f_ra, f->f_mapping->host->i_mapping);

fs/Kconfig +30 -0

@@ -265,4 +265,34 @@ endif
 source "fs/nls/Kconfig"
 source "fs/dlm/Kconfig"
 
+config PROC_FILECACHE
+	tristate "/proc/filecache support"
+	default m
+	depends on PROC_FS
+	help
+	  This option creates a file /proc/filecache which enables one to
+	  query/drop the cached files in memory.
+
+	  A quick start guide:
+
+	  # echo 'ls' > /proc/filecache
+	  # head /proc/filecache
+
+	  # echo 'cat /bin/bash' > /proc/filecache
+	  # head /proc/filecache
+
+	  # echo 'drop pagecache' > /proc/filecache
+	  # echo 'drop slabcache' > /proc/filecache
+
+	  For more details, please check Documentation/filesystems/proc.txt .
+
+	  It can be a handy tool for sysadms and desktop users.
+
+config PROC_FILECACHE_EXTRAS
+	bool "track extra states"
+	default y
+	depends on PROC_FILECACHE
+	help
+	  Track extra states that costs a little more time/space.
+
 endmenu

Quoted 28 lines · Wu Fengguang

Quoted 10 lines · Frederic Weisbecker

Quoted 7 lines · Wu Fengguang

On Tue, Apr 28, 2009 at 08:17:51PM +0800, Ingo Molnar wrote:

There are two possible challenges for the conversion:

- One trick it does is to select different lists to traverse on different filter options. Will this be possible in the object tracing framework?

Yeah, I guess.

Great.

Quoted 10 lines

Quoted 4 lines

- The file name lookup(last field) is the performance killer. Is it possible to skip the file name lookup when the filter failed on the leading fields?

objects collection lays on trace events where filters basically ignore a whole entry in case of non-matching. Not sure if we can easily only ignore one field.

But I guess we can do something about the performances...

OK, but it's not as important as the previous requirement, so it could be the last thing to work on :)

Quoted 7 lines

Quoted 2 lines

Could you send us the (sob'ed) patch you made which implements this. I could try to adapt it to object collection.

Attached for your reference. Be aware that I still have plans to change it in non trivial way, and there are ongoing works by Nick(on inode_lock) and Jens(on s_dirty) that can create merge conflicts. So basically it is not a right time to do the adaption.

Ah ok, so I will wait a bit :-)

Quoted 9 lines

However we can still do something to polish up the page object collection under /debug/tracing/objects/mm/pages/. For example, the timestamps and function name could be removed from the following list :)

# tracer: nop
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |

Quoted 11 lines

           <...>-3743  [001]  3035.649769: dump_pages: pfn=1 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176403: dump_pages: pfn=1 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176407: dump_pages: pfn=2 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176408: dump_pages: pfn=3 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176409: dump_pages: pfn=4 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176409: dump_pages: pfn=5 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176410: dump_pages: pfn=6 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176410: dump_pages: pfn=7 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176411: dump_pages: pfn=8 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176411: dump_pages: pfn=9 flags=400 count=1 mapcount=0 index=0
           <...>-3743  [001]  3044.176412: dump_pages: pfn=10 flags=400 count=1 mapcount=0 index=0

echo nocontext-info > /debug/tracing/trace_options :-)

But you'll have only the function and the pages specifics. It's not really the function but more specifically the name of the event. It's useful to distinguish multiple events to a trace.

Hmm, may be it's not that much useful in a object dump...

Quoted 2 lines

Could you send us the (sob'ed) patch you made which implements this. I could try to adapt it to object collection.

Attached for your reference. Be aware that I still have plans to change it in non trivial way, and there are ongoing works by Nick(on inode_lock) and Jens(on s_dirty) that can create merge conflicts. So basically it is not a right time to do the adaption.

Hi

Quoted 3 lines

Quoted 2 lines

Could you send us the (sob'ed) patch you made which implements this. I could try to adapt it to object collection.

Quoted 4 lines

Attached for your reference. Be aware that I still have plans to change it in non trivial way, and there are ongoing works by Nick(on inode_lock) and Jens(on s_dirty) that can create merge conflicts. So basically it is not a right time to do the adaption.

if you can make object collection based filecache viewer, could you please cc me? I guess I can review it in mm part.

But it has to be expressed in one framework that cares about the totality of the kernel - not just these splintered bits of

Quoted 44 lines · Wu Fengguang

Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.

1) for kernel hackers (on CONFIG_DEBUG_KERNEL)
- all available page flags are exported, and
- exported as is
2) for admins and end users
- only the more `well known' flags are exported:
11. KPF_MMAP (pseudo flag) memory mapped page
12. KPF_ANON (pseudo flag) memory mapped page (anonymous)
13. KPF_SWAPCACHE page is in swap cache
14. KPF_SWAPBACKED page is swap/RAM backed
15. KPF_COMPOUND_HEAD (*)
16. KPF_COMPOUND_TAIL (*)
17. KPF_UNEVICTABLE page is in the unevictable LRU list
18. KPF_HWPOISON hardware detected corruption
19. KPF_NOPAGE (pseudo flag) no page frame at the address

(*) For compound pages, exporting _both_ head/tail info enables
users to tell where a compound page starts/ends, and its order.

- limit flags to their typical usage scenario, as indicated by KOSAKI:
- LRU pages: only export relevant flags
- PG_lru
- PG_unevictable
- PG_active
- PG_referenced
- page_mapped()
- PageAnon()
- PG_swapcache
- PG_swapbacked
- PG_reclaim
- no-IO pages: mask out irrelevant flags
- PG_dirty
- PG_uptodate
- PG_writeback
- SLAB pages: mask out overloaded flags:
- PG_error
- PG_active
- PG_private
- PG_reclaim: mask out the overloaded PG_readahead
- compound flags: only export huge/gigantic pages

Here are the admin/linus views of all page flags on a newly booted nfs-root system:

Quoted 7 lines

# ./page-types # for admin
         flags  page-count       MB  symbolic-flags                     long-symbolic-flags
0x000000000000      491174     1918  ____________________________                
0x000000000020           1        0  _____l______________________       lru      
0x000000000028        2543        9  ___U_l______________________       uptodate,lru
0x00000000002c        5288       20  __RU_l______________________       referenced,uptodate,lru
0x000000004060           1        0  _____lA_______b_____________       lru,active,swapbacked

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation measures are being accepted into the MM while other, more dynamic and more flexible MM instrumentation are being resisted by Andrew.

The above type of condensed information can be built out of dynamic trace data too - and much more. Being able to track page state transitions is very valuable when debugging VM problems. One such 'view' of trace data would be a summary histogram like above.

( done after a "echo 3 > /proc/sys/vm/drop_caches" to make sure all
interesting pages have been re-established and their state is present in the trace. )

The SLAB code already has such a facility, kmemtrace: it's very useful and successful in visualizing complex SLAB details, both dynamically and statically.

I think the same general approach should be used for the page allocator too (and for the page cache and some other struct page based caches): the life-time of an object should be followed. If we capture the important details we capture the big picture too. Pekka already sent an RFC patch to extend kmemtrace in such a fashion. Why is that more useful method not being pursued?

By extending upon the (existing) /proc/kpageflags hack a usecase is taken away from the tracing based solution and a needless overlap is created - and that's not particularly helpful IMHO. We now have all the facilities upstream that allow us to do intelligent instrumentation - we should make use of them.

Ingo

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

Quoted 55 lines · Ingo Molnar

Quoted 44 lines · Wu Fengguang

Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.

1) for kernel hackers (on CONFIG_DEBUG_KERNEL)
- all available page flags are exported, and
- exported as is
2) for admins and end users
- only the more `well known' flags are exported:
11. KPF_MMAP (pseudo flag) memory mapped page
12. KPF_ANON (pseudo flag) memory mapped page (anonymous)
13. KPF_SWAPCACHE page is in swap cache
14. KPF_SWAPBACKED page is swap/RAM backed
15. KPF_COMPOUND_HEAD (*)
16. KPF_COMPOUND_TAIL (*)
17. KPF_UNEVICTABLE page is in the unevictable LRU list
18. KPF_HWPOISON hardware detected corruption
19. KPF_NOPAGE (pseudo flag) no page frame at the address

(*) For compound pages, exporting _both_ head/tail info enables
users to tell where a compound page starts/ends, and its order.

- limit flags to their typical usage scenario, as indicated by KOSAKI:
- LRU pages: only export relevant flags
- PG_lru
- PG_unevictable
- PG_active
- PG_referenced
- page_mapped()
- PageAnon()
- PG_swapcache
- PG_swapbacked
- PG_reclaim
- no-IO pages: mask out irrelevant flags
- PG_dirty
- PG_uptodate
- PG_writeback
- SLAB pages: mask out overloaded flags:
- PG_error
- PG_active
- PG_private
- PG_reclaim: mask out the overloaded PG_readahead
- compound flags: only export huge/gigantic pages

Here are the admin/linus views of all page flags on a newly booted nfs-root system:

Quoted 7 lines

# ./page-types # for admin
         flags  page-count       MB  symbolic-flags                     long-symbolic-flags
0x000000000000      491174     1918  ____________________________                
0x000000000020           1        0  _____l______________________       lru      
0x000000000028        2543        9  ___U_l______________________       uptodate,lru
0x00000000002c        5288       20  __RU_l______________________       referenced,uptodate,lru
0x000000004060           1        0  _____lA_______b_____________       lru,active,swapbacked

Quoted 4 lines

I think i have to NAK this kind of ad-hoc instrumentation of kernel internals and statistics until we clear up why such instrumentation measures are being accepted into the MM while other, more dynamic and more flexible MM instrumentation are being resisted by Andrew.

An unexpected NAK - to throw away an orange because we are to have an apple? ;-)

Anyway here are the missing rationals.

1) FAST

It takes merely 0.2s to scan 4GB pages:

        ./page-types  0.02s user 0.20s system 99% cpu 0.216 total

2) SIMPLE

/proc/kpageflags will be a *long standing* hack we have to live with - it was originally introduced by Matt to do shared memory accounting and a facility to analyze applications' memory consumptions, with the hope it will also help kernel developers someday.

So why not extend and embrace it, in a straightforward way?

3) USE CASES

I have/will take advantage of the above page-types command in a number ways:
- to help track down memory leak (the recent trace/ring_buffer.c case)
- to estimate the system wide readahead miss ratio
- Andi want to examine the major page types in different workloads (for the hwpoison work)
- Me too, for fun of learning: read/write/lock/whatever a lot of pages and examine their flags, to get an idea of some random kernel behaviors. (the dynamic tracing tools can be more helpful, as a different view)

4) COMPLEMENTARITY

In some cases the dynamic tracing tool is not enough (or too complex) to rebuild the current status view.

I myself have a dynamic readahead tracing tool(very useful!). At the same time I also use readahead accounting numbers, and the /proc/filecache tool(frequently!), and the above page-types tool. I simply need them all - they are handy for different cases.

1) FAST

It takes merely 0.2s to scan 4GB pages:

       ./page-types  0.02s user 0.20s system 99% cpu 0.216 total

Quoted 5 lines · Wu Fengguang

1) FAST

It takes merely 0.2s to scan 4GB pages:

       ./page-types  0.02s user 0.20s system 99% cpu 0.216 total

OK on a tiny system ... but sounds painful on a big server. 0.2s for 4G scales up to 3 minutes 25 seconds on a 4TB system (4TB systems were being sold two years ago ... so by now the high end will have moved up to 8TB or perhaps 16TB).

Would the resulting output be anything but noise on a big system (a *lot* of pages can change state in 3 minutes)?

Bah. The rate of change is proportional to #cpus, not #pages. Assuming you've got 1024 processors, you could run the scan in parallel in .2 seconds still.

Quoted 3 lines · Matt Mackall

Bah. The rate of change is proportional to #cpus, not #pages. Assuming you've got 1024 processors, you could run the scan in parallel in .2 seconds still.

That would help ... it would also make the patch to support this functionality a lot more complex.

Quoted 3 lines · Matt Mackall

Bah. The rate of change is proportional to #cpus, not #pages. Assuming you've got 1024 processors, you could run the scan in parallel in .2 seconds still.

That would help ... it would also make the patch to support this functionality a lot more complex.

Quoted 5 lines · Wu Fengguang

1) FAST

It takes merely 0.2s to scan 4GB pages:

__ __ __ __./page-types __0.02s user 0.20s system 99% cpu 0.216 total

OK on a tiny system ... but sounds painful on a big server. 0.2s for 4G scales up to 3 minutes 25 seconds on a 4TB system (4TB systems were being sold two years ago ... so by now the high end will have moved up to 8TB or perhaps 16TB).

Would the resulting output be anything but noise on a big system (a *lot* of pages can change state in 3 minutes)?

Quoted 13 lines · On Tue, 28 Apr 2009 11:11:52 -0700 Tony Luck <[email protected]> wrote:

Quoted 5 lines · Wu Fengguang

1) FAST

It takes merely 0.2s to scan 4GB pages:

__ __ __ __./page-types __0.02s user 0.20s system 99% cpu 0.216 total

OK on a tiny system ... but sounds painful on a big server. 0.2s for 4G scales up to 3 minutes 25 seconds on a 4TB system (4TB systems were being sold two years ago ... so by now the high end will have moved up to 8TB or perhaps 16TB).

Quoted 4 lines

Would the resulting output be anything but noise on a big system (a *lot* of pages can change state in 3 minutes)?

Reading the state of all of memory in this fashion would be a somewhat peculiar thing to do.

Generally, I think that pagemap is another of those things where we've failed on the follow-through. There's a nice and powerful interface for inspecting the state of a process's VM, but nobody knows about it and there are no tools for accessing it and nobody is using it.

Quoted 2 lines

Reading the state of all of memory in this fashion would be a somewhat peculiar thing to do.

Not entirely. If you've got, say, a large NUMA box, it could be incredibly illustrative to see that "oh, this node is entirely dominated by SLAB allocations". Or on a smaller machine "oh, this is fragmented to hell and there's no way I'm going to get a huge page". Things you're not going to get from individual stats.

plain text document attachment (kpageflags-extending.patch) Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.

Quoted 2 lines · Wu Fengguang

plain text document attachment (kpageflags-extending.patch) Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.

My only concern with this patch is it knows a bit too much about SLUB internals (and perhaps not enough about SLOB, which also overloads flags).

Quoted 7 lines · Matt Mackall

Quoted 2 lines · Wu Fengguang

plain text document attachment (kpageflags-extending.patch) Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.

My only concern with this patch is it knows a bit too much about SLUB internals (and perhaps not enough about SLOB, which also overloads flags).

Yup. PG_private=PG_slob_free is not masked because SLOB actually does not set PG_slab at all. I wonder if it's safe to do this change:

        /* SLOB */

In the page-types output:

         flags  page-count       MB  symbolic-flags                     long-symbolic-flags
0x000800000040        7113       27  ______A_________________P____      active,private
0x000000000040          66        0  ______A______________________      active

The above two lines are obviously for SLOB pages. It indicates lots of free SLOB pages. So my question is:

- Do you have other means to get the nr_free_slobs info? (I found none in the code) or
- Will exporting the SL*B overloaded flags going to help?

Quoted 12 lines · Wu Fengguang

Quoted 7 lines · Matt Mackall

Quoted 2 lines · Wu Fengguang

plain text document attachment (kpageflags-extending.patch) Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.

My only concern with this patch is it knows a bit too much about SLUB internals (and perhaps not enough about SLOB, which also overloads flags).

Yup. PG_private=PG_slob_free is not masked because SLOB actually does not set PG_slab at all. I wonder if it's safe to do this change:

Review

Quoted 4 lines

        /* SLOB */

(quoted diff) +1 -1

-       PG_slob_page = PG_active,
+       PG_slob_page = PG_slab,
        PG_slob_free = PG_private,

Yep.

Quoted 8 lines

In the page-types output:

         flags  page-count       MB  symbolic-flags                     long-symbolic-flags
0x000800000040        7113       27  ______A_________________P____      active,private
0x000000000040          66        0  ______A______________________      active

The above two lines are obviously for SLOB pages. It indicates lots of free SLOB pages. So my question is:

Free here just means partially allocated.

Quoted 3 lines

- Do you have other means to get the nr_free_slobs info? (I found none in the code) or
- Will exporting the SL*B overloaded flags going to help?

Yes, it's useful.

fs/proc/page.c static const struct file_operations proc · line 123

Quoted 5 lines

fs/proc/page.c +5 -0

+#define kpf_copy_bit(uflags, kflags, visible, ubit, kbit)		\
+	do {								\
+		if (visible || genuine_linus())				\
+			uflags |= ((kflags >> kbit) & 1) << ubit;	\
+	} while (0);

Did this have to be implemented as a macro?

It's bad, because it might or might not reference its argument, so if someone passes it an expression-with-side-effects, the end result is unpredictable. A C function is almost always preferable if possible.

Quoted 8 lines

fs/proc/page.c +8 -0

+/* a helper function _not_ intended for more general uses */
+static inline int page_cap_writeback_dirty(struct page *page)
+{
+	struct address_space *mapping;
+
+	if (!PageSlab(page))
+		mapping = page_mapping(page);
+	else

fs/proc/page.c static const struct file_operations proc · line 136

Quoted 4 lines

fs/proc/page.c +4 -0

+		mapping = NULL;
+
+	return mapping && mapping_cap_writeback_dirty(mapping);
+}

If the page isn't locked then page->mapping can be concurrently removed and freed. This actually happened to me in real-life testing several years ago.

Quoted 8 lines

Quoted 8 lines

fs/proc/page.c +8 -0

+/* a helper function _not_ intended for more general uses */
+static inline int page_cap_writeback_dirty(struct page *page)
+{
+	struct address_space *mapping;
+
+	if (!PageSlab(page))
+		mapping = page_mapping(page);
+	else

Quoted 8 lines

fs/proc/page.c static const struct file_operations proc · line 136

Quoted 4 lines

fs/proc/page.c +4 -0

+		mapping = NULL;
+
+	return mapping && mapping_cap_writeback_dirty(mapping);
+}

If the page isn't locked then page->mapping can be concurrently removed and freed. This actually happened to me in real-life testing several years ago.

We certainly don't want to be taking locks per page to build the flags data here. As we don't have any pretense of being atomic, it's ok if we can find a way to do the test that's inaccurate when a race occurs, so long as it doesn't dereference null.

But if there's not an obvious way to do that, we should probably just drop this flag bit for this iteration.

Quoted 22 lines · On Tue, 28 Apr 2009 17:46:34 -0500 Matt Mackall <[email protected]> wrote:

Quoted 8 lines

Quoted 8 lines

fs/proc/page.c +8 -0

+/* a helper function _not_ intended for more general uses */
+static inline int page_cap_writeback_dirty(struct page *page)
+{
+	struct address_space *mapping;
+
+	if (!PageSlab(page))
+		mapping = page_mapping(page);
+	else

Quoted 8 lines

fs/proc/page.c static const struct file_operations proc · line 136

Quoted 4 lines

fs/proc/page.c +4 -0

+		mapping = NULL;
+
+	return mapping && mapping_cap_writeback_dirty(mapping);
+}

If the page isn't locked then page->mapping can be concurrently removed and freed. This actually happened to me in real-life testing several years ago.

We certainly don't want to be taking locks per page to build the flags data here. As we don't have any pretense of being atomic, it's ok if we can find a way to do the test that's inaccurate when a race occurs, so long as it doesn't dereference null.