All of lore.kernel.org
 help / color / mirror / Atom feed
* Metadata hit ratio
@ 2010-06-24 20:30 Yannis Klonatos
  2010-06-25  1:15 ` Dave Chinner
  0 siblings, 1 reply; 2+ messages in thread
From: Yannis Klonatos @ 2010-06-24 20:30 UTC (permalink / raw)
  To: xfs

Hello all,

         Along with my other (yet pending :-( ) question/issue, I have 
another question (i hope this is the last :-) )
now.
         I would like to measure the hit ratio of the metadata accesses 
of XFS (inode+internal buffers). It is my
understanding that XFS uses its own data structures, and does not rely 
on the buffercache mechanisms of
the Linux kernel. However, even doing so, there may be cases that the 
metadata may not fit in the RAM,
and I/O operations are required to fetch them from the underlying 
storage. I have found out that there are
two places that XFS uses the submit_bio function. If i add some counters 
there, would it suffice to measure all
the metadata misses?
         Or is this information available in one (or more) of the 
xfs_stats counters? And if so, what do i need to sum
up in order to get the total metadata hit and miss ratio?

Thanks (again!) in advance,
Yannis Klonatos

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Metadata hit ratio
  2010-06-24 20:30 Metadata hit ratio Yannis Klonatos
@ 2010-06-25  1:15 ` Dave Chinner
  0 siblings, 0 replies; 2+ messages in thread
From: Dave Chinner @ 2010-06-25  1:15 UTC (permalink / raw)
  To: Yannis Klonatos; +Cc: xfs

On Thu, Jun 24, 2010 at 11:30:44PM +0300, Yannis Klonatos wrote:
> Hello all,
> 
>         Along with my other (yet pending :-( ) question/issue, I
> have another question (i hope this is the last :-) )
> now.
>         I would like to measure the hit ratio of the metadata
> accesses of XFS (inode+internal buffers). It is my
> understanding that XFS uses its own data structures, and does not
> rely on the buffercache mechanisms of
> the Linux kernel. However, even doing so, there may be cases that
> the metadata may not fit in the RAM,
> and I/O operations are required to fetch them from the underlying
> storage. I have found out that there are
> two places that XFS uses the submit_bio function. If i add some
> counters there, would it suffice to measure all
> the metadata misses?
>         Or is this information available in one (or more) of the
> xfs_stats counters? And if so, what do i need to sum
> up in order to get the total metadata hit and miss ratio?

Start by looking here:

http://xfs.org/index.php/Runtime_Stats

But you probably want some of the buf counters which are
undocumented on that page, so a rough description of them is
(from PCP):

$ pminfo -t xfs.buffer
xfs.buffer.get [number of request buffer calls]
xfs.buffer.create [number of buffers created]
xfs.buffer.get_locked [number of requests for a locked buffer which succeeded]
xfs.buffer.get_locked_waited [number of requests for a locked buffer which waited]
xfs.buffer.busy_locked [number of non-blocking requests for a locked buffer which failed]
xfs.buffer.miss_locked [number of requests for a locked buffer which failed due to no buffer]
xfs.buffer.page_retries [number of retry attempts when allocating a page for insertion in a buffer]
xfs.buffer.page_found [number of hits in the page cache when looking for a page]
xfs.buffer.get_read [number of buffer get calls requiring immediate device reads]

So you might be able to get something from those stats.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-06-25  1:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-24 20:30 Metadata hit ratio Yannis Klonatos
2010-06-25  1:15 ` Dave Chinner

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.