[Xen-devel] Re: [Xen-users] cache for partition based VBD?

[Tim Freeman <tfreeman@xxxxxxxxxxx>]

Thanks for responding,

On Tue, 29 Nov 2005 18:56:32 +0100
"Petersson, Mats" <mats.petersson@xxxxxxx> wrote:

> > -----Original Message-----
> > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> > Tim Freeman
> > Sent: 29 November 2005 17:12
> > To: xen-users@xxxxxxxxxxxxxxxxxxx
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [Xen-users] cache for partition based VBD?
> > 
> > For partition backed VBDs, is there still an effective cache 
> > in dom0?  The Linux buffer cache will affect file based VBDs, 
> > but does the partition backed VBD get around it? 
> 
> Let's first start with the facts:  don't know the answer to your
> question 
> 
> Now for some speculation: 
> The block device cache would be efficient in the sense that it's useful
> for every type of file-system, and it's not going to have to be clever
> about what sort of accesses are frequent, not so frequent etc. This
> gives benefit to the "cache at the device level".

I'm looking into this a little, reading chapter 15 of Robert Love's 'Linux
Kernel Development,' here is a good bit: 

"Individual disk blocks can also tie into the page cache, by way of block I/O
buffers [...] this caching is often referred to as the "buffer cache," although
in reality it is not a separate cache and is part of the page cache."

(the difference here is that the page is larger than the disk block and this I/O
buffer actually describes the mapping of block onto a page... also, he notes
back in Linux 2.2 they used to be separate caches)

He explans there is a temporal locality algorithm *by page* not with any
preference for filesystem structures.

> On the other hand, a file-system level cache would also make sense.
> Caching directory structurs or file-allocation-table [not necessarily in
> the Microsoft sense] would obviously help a whole lot more than caching
> some block from the middle of a file that isn't ever going to be read
> again. This motivates having a targetted caching mechanism in the
> file-system (VFS) layer. 

This also happening somewhat, found this statement:

"The Linux VFS layer attempts to cache inodes in memory; this cache is
maintained by a linked list of dentry structures. Each dentry contains a
reference to the inode, and the name of the file. "

http://www.kevinboone.com/linux_kernel_file_1.html

Writing+filesystem-cache seems more complicated, but I'm not worried about this
right now, this talk seems to have a lot of good info on that for ext3:

http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html

I am continuing to look for Xen specific device driver + buffer cache (w/
partition based VBD) evidence besides our experiment.  We're going to run a new
test w/ this setup as well, running sar or vmstat in dom0, but I'd still like to
have code/documentation/xen-developer evidence if possible.  Also looking for
ways of clearing the buffer cache entirely (not just flushing writes). 

Thanks,
Tim



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel