All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yannis Klonatos <klonatos@ics.forth.gr>
To: Andi Kleen <andi@firstfloor.org>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_buf and buffercache/pagecache connection
Date: Mon, 31 May 2010 21:25:29 +0300	[thread overview]
Message-ID: <4C03FF19.2070608@ics.forth.gr> (raw)
In-Reply-To: <87aargt0ap.fsf@basil.nowhere.org>


[-- Attachment #1.1: Type: text/plain, Size: 2259 bytes --]

???? 5/31/2010 9:04 PM, O/H Andi Kleen ??????:
> Yannis Klonatos<klonatos@ics.forth.gr>  writes:
>
>    
>>          I was looking to add a kernel hook to my system in order to
>> monitor buffer-cache hit and misses. Initially I was
>> planning to add my modifications to the __getblk(). However, i noticed
>> that XFS does not directly use the buffer-cache
>> for its pages but it seems to implement its own buffer.
>>          What I am now looking for is 1) the place where XFS checks
>> whether a page exists in its buffer or not and 2)
>> what are the possible interactions between xfs_buf and the Linux
>> kernel buffer-cache.
>>          I would appreciate any information regarding the above issues.
>>      
> The kernel does not track all accesses, e.g. through mmap.
> So you can only get misses (which is essentially IO rate and already
> accounted), but not hits.
>
> -Andi
>    

First of all thanks for your quick reply.

So, if i understand correctly, what you are saying is that it is 
basically impossible to modify xfs code
so that i get that specific information? This sounds a bit strange since 
if XFS was indeed using the
buffercache as ext3 or other fs does, the following modification would 
suffice (file fs/buffer.c):

structbuffer_head  <+code=buffer_head>  *
find_get_block  <+code=__find_get_block>(structblock_device  <+code=block_device>  *bdev  <+code=bdev>,sector_t  <+code=sector_t>  block  <+code=block>, intsize  <+code=size>) {

      	structbuffer_head  <+code=buffer_head>  *bh  <+code=bh>  =lookup_bh_lru  <+code=lookup_bh_lru>(bdev  <+code=bdev>,block  <+code=block>,size  <+code=size>);
	/* BEGIN MODIFICATION */
	if (bh) buffercache_hits++;
	else buffercache_misses++;
	/* END MODIFICATION */
         if (bh  <+code=bh>  ==NULL  <+code=NULL>) {
                bh  <+code=bh>  =__find_get_block_slow  <+code=__find_get_block_slow>(bdev  <+code=bdev>,block  <+code=block>);
                if (bh  <+code=bh>)
                        bh_lru_install  <+code=bh_lru_install>(bh  <+code=bh>);
        }
        if (bh  <+code=bh>) {
                touch_buffer  <+code=touch_buffer>(bh  <+code=bh>);
        returnbh  <+code=bh>;

}

XPORT_SYMBOL  <+code=EXPORT_SYMBOL>(__find_get_block  <+code=__find_get_block>);



[-- Attachment #1.2: Type: text/html, Size: 4086 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2010-05-31 18:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-31 16:31 xfs_buf and buffercache/pagecache connection Yannis Klonatos
2010-05-31 18:04 ` Andi Kleen
2010-05-31 18:25   ` Yannis Klonatos [this message]
2010-05-31 22:06 ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C03FF19.2070608@ics.forth.gr \
    --to=klonatos@ics.forth.gr \
    --cc=andi@firstfloor.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.