[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    Re: [Evms-devel] Kernel memory questions
From:       Andrew Clausen <clausen () gnu ! org>
Date:       2001-10-03 15:22:05
[Download RAW message or body]

On Wed, Oct 03, 2001 at 01:33:11PM -0500, Kevin Corry wrote:
> > I posted in my other email a possible solution for this (I don't know if it
> > will be good or bad in the end).  Since a large majority of LVs are on disk
> > contiguously, you can use a runlist to store them.  The worst case scenario
> > would be to have the LEs allocated on disk in reverse PE order, but this
> > is highly unlikely.  Conversely, the common case (contiguous LV or only a
> > few "runs") will be much more efficient to store and will improve locality
> > of memory reference a great deal (i.e. use cache better).  It is always
> > good to optimize for the common case.
> 
> I agree that the run-list method would probably improve data locality, but at 
> the expense of increased translation time.

"Locality of reference" means fewer L1 cache misses.  In the LVM2 driver,
the size of a node in the btree is the size of an L1 cache line, so the
maximum number of cache lines used will be O(log N), where N is the
number of runs.

If you need to map many blocks that are near each other at the same time,
then the path down the b-tree will be largely the same, so you would
expect many hits.

So, I wouldn't expect run-lists with a btree implementation to have a worse
translation time.  I'm just ranting, I haven't benchmarked it ;)

Andrew

[prev in list] [next in list] [prev in thread] [next in thread]