Re: [RFC] the /proc/filecache interface

[Fengguang Wu <fengguang.wu@gmail.com>]

Hi Pavel,

On Wed, Jun 14, 2006 at 01:05:42PM +0200, Pavel Machek wrote:
> > The /proc/filecache support has been half done. And I'd like to hear
> > early comments on the interface.
> > 
> > (The patch is not quite ready for code reviews. It is attached in case
> > someone are interested to have it a try.)
> 
> I guess this is going to be nice for loading cache after
> suspend-to-disk and for the fast boot, but...

Thanks.

> > SAMPLE OUTPUT
> > 
> > root ~# echo -n ALL > /proc/filecache
> > root ~# head /proc/filecache
> > # file ALL
> > #      ino       size   cached cached%  state   refcnt  uid     gid     dev             file
> >     413605         23       24    100   --      0       0       0       03:00(hda)      /sbin/modprobe
> >     381701         17       20    100   --      1       0       0       03:00(hda)      /bin/cat
> >     398088          1        4    100   --      0       0       0       03:00(hda)      /root/bin/checkpath
> >     381698        611      612    100   --      1       0       0       03:00(hda)      /bin/bash
> >     159498          1        4    100   --      0       0       0       03:00(hda)      /etc/mtab
> >     381719         30       32    100   --      0       0       0       03:00(hda)      /bin/rm
> >     335993          4        4    100   --      0       0       43      03:00(hda)      /var/run/utmp
> >          0    3687424      828      0   --      0       0       0       00:02(bdev)     03:00
> >     159701          5        8    100   --      0       0       0       03:00(hda)      /etc/modprobe.d/aliases
> >      31866       1238     1240    100   --      4       0       0       03:00(hda)      /lib/tls/libc-2.3.5.so
> >     381705         51       52    100   --      0       0       0       03:00(hda)      /bin/cp
> >      31814         27       28    100   --      0       0       0       03:00(hda)      /lib/libblkid.so.1.0
> >     159534         17       20    100   --      0       0       0       03:00(hda)      /etc/ld.so.cache
> > [...]
> 
> > root ~# echo -n /lib/tls/libc-2.3.5.so > /proc/filecache
> > root ~# head /proc/filecache
> > # file /lib/tls/libc-2.3.5.so
> > # flags LK:locked ER:error RF:referenced UD:uptodate DT:dirty AC:active SL:slab CK:checked A1:arch_1 RS:reserved PV:private WB:writeback NS:nosave CP:compound SC:swapcache MD:mappedtodisk RC:reclaim ns:nosave_free RA:readahead MM:mmap
> > # idx   len                     state                   	refcnt  location
> > 0       21      ____RFUD__AC__________________MD______MM        4       0.0.Normal
> > 21      1       ____RFUD__AC__________________MD______MM        3       0.0.Normal
> > 22      3       ______UD______________________MD________        1       0.0.Normal
> > 25      1       ____RFUD__AC__________________MD______MM        2       0.0.Normal
> > 26      2       ______UD______________________MD________        1       0.0.Normal
> > 28      1       ______UD______________________MD____RA__        1       0.0.Normal
> > 29      2       ______UD______________________MD________        1       0.0.Normal
> 
> The interface is really too ugly to live. How do you expect it being
> used from two programs, simultaneously?

Yes, it can be used by two programs without interfering each other :)
The trick goes in this way:
        - program A, B each opened the /proc/filecache for querying
        - A calls fdA = open("/proc/filecache")
        - B calls fdB = open("/proc/filecache")
        - A calls write(fdA, "file /lib/tls/libc-2.3.5.so") to set
          parameter, which will be stored in fileA->f_version.
        - the same for B
        - so A, B each has its own working parameter.

There is also a global parameter, which will be used if the program
has not call write() to set his own parameter. I'll take care so that
programs that query the interface do not pollute the global default
parameter:
        - open(); write(); close()
                save the private parameter as the global default
        - open(); write(); ...; read(); close()
                do not touch the global parameter
        - open(); read(); close()
                initialize the private parameter with the global default

> We don't really want to do ascii pretty-printing in kernel, sorry. It

You mean the page flags? I bet sysadms would like it ;)
Another consideration of not using hex numbers is to prevent
PG_referenced being adapted to 12 someday.

And I never mean to expose so much flags. If any page flag is supposed
to be useless for the user(i.e. SL:slab), please let me know, thanks.

> probably needs to go into /sys , and be redesigned to provide "one
> value per file" rule...

I choose not to use /sys to avoid overheads. It requires allocating
much more structs, and injecting hooks to respond to inode
create/remove events.

Thanks,
Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/