Re: ext4 extent status tree LRU locking
From: Zheng Liu
Date: Thu Jun 13 2013 - 09:09:15 EST
Hi Ted,
On Wed, Jun 12, 2013 at 04:48:54PM -0400, Theodore Ts'o wrote:
> On Wed, Jun 12, 2013 at 08:09:14AM -0700, Dave Hansen wrote:
> > You could make per-cpu LRUs, and batch movement on and off the global
> > LRU once the local ones get to be a certain size. Or, you could keep
> > them cpu-local *until* the shrinker is called, when the shrinker could
> > go drain all the percpu ones.
> >
> > Or, you could tag each extent in memory with its last-used time. You
> > write an algorithm to go and walk the tree and attempt to _generally_
> > free the oldest objects out of a limited window.
>
> Another approach might be to tag each inode with the last time an
> ext4_map_blocks() was called on the inode, and keep an unsorted list
> of inodes which has one or more entries in the extent cache.
>
> When we decide to discard entries from the extent cache, we should
> drop all of the entries for the inode --- and then when we read in
> part of the extent tree leaf block, we should create entries in the
> extent cache for all of the extents found in the extent leaf block.
Thanks for your suggestion. But, sorry, I couldn't get your point here.
As you suggested above, we can tag each inode with the last access time
when ext4_map_blocks() is called. Then we will get an unsorted list of
inodes with some extent entries. When we tries to reclaim some entries
from extent cache, we can call list_sort() to get an sorted list of
inodes and try to reclaim some entries according to the last access
time. My question is why do we need to drop all of the entries from all
inodes.
Af far as I understand, we can do the following improvement. We tag the
last access time for each inode. So that would avoid to move the inode
in lru list frequently. When we try to reclaim some entries, we call
list_sort() to get a sorted lru list, and drop some entries from lru
list. Please correct me if I misunderstood.
For creating all extent leaf blocks, that is another improvement. I
will try to add it after I solve current problem that Dave reported.
Thanks,
- Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/