On Tue, May 02, 2006 at 08:55:06AM -0700, Linus Torvalds wrote:
> So I would _seriously_ claim that the place to do all the statistics
> allocation is in anything that ends up having to call "->readpage()", and
> do it all on a virtual mapping level.
>
> Yes, it isn't perfect either (I'll mention some problems), but it's a
> _lot_ better. It means that when you gather the statistics, you can see
> the actual _files_ and offsets being touched. You can even get the
> filenames by following the address space -> inode -> i_dentry list.
>
> This is important for several reasons:
> (a) it makes it a hell of a lot more readable, and the user gets a
> lot more information that may make him see the higher-level issues
> involved.
> (b) it's in the form that we cache things, so if you read-ahead in
> that form, you'll actually get real information.
> (c) it's in a form where you can actually _do_ something about things
> like fragmentation etc ("Oh, I could move these files all to a
> separate area")
There have been two alternatives for me:
1) static/passive interface i.e. the /proc/filecache querier
- user-land tools request to dump the cache contents on demand
2) dynamic/active interface i.e. the readpage() logger
- user-land daemon accepts live page access/io activities
> Now, admittedly it has a few downsides:
>
> - right now "readpage()" is called in several places, and you'd have to
> create some kind of nice wrapper for the most common
> "mapping->a_ops->readpage()" thing and hook into there to avoid
> duplicating the effort.
>
> Alternatively, you could decide that you only want to do this at the
> filesystem level, which actually simplifies some things. If you
> instrument "mpage_readpage[2]()", you'll already get several of the
> ones you care about, and you could do the others individually.
>
> [ As a third alternative, you might decide that the only thing you
> actually care about is when you have to wait on a locked page, and
> instrument the page wait-queues instead. ]
>
> - it will miss any situation where a filesystem does a read some other
> way. Notably, in many loads, the _directory_ accesses are the important
> ones, and if you want statistics for those you'd often have to do that
> separately (not always - some of the filesystems just use the same
> page reading stuff).
>
> The downsides basically boil down to the fact that it's not as clearly
> just one single point. You can't just look at the request queue and see
> what physical requests go out.
Good insights.
The readpage() activities logging idea has been appealing for me.
We might even go further to log mark_page_accessed() calls for more
information.
This approach is more precise, and provides process/page
correlations and time info that the /proc/filecache interface cannot
provide. Though it involves more complexity and overhead(for me they
mean the possibility of being rejected:).
Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
