On Mon, Apr 21, 2014 at 10:05:23AM -0400, Theodore Ts'o wrote:
[...]
> > Second question is about your deeply thought. From your comment, it
> > seems that now we need a replacement algorithm that looks like we do in
> > memory management subsystem. Now in memory management subsystem, we
> > have an active list and an inactive list which tracks some pages. When
> > the system read/write some pages, these pages will be put on inactive
> > list. Then if some pages are accessed again, they will be promoted into
> > active list. When 'kswapd' thread tries to reclaim some pages, it will
> > drop some pages from inactive list and demote some pages from active
> > list to inactive list. I am happy to give it a try later.
>
> Yes, although we'll need to be careful that we don't introduce
> scalability problems caused by needing to take too many locks. So I
> don't think we want to move items from the inactive to active list
> when the extent cache is referenced. Instead, we'll probably want to
> bump a ref count in the cache entry, and then in the shrinker, when we
> scan the inactive list, we can check the ref count and decide then to
> move the item to the active list. That way, only the shrinker needs
> to take the global lock.
I am not sure that I fully understand your meaning. AFAIU, we have a
list which uses RR scheme to shrink extent caches. In this list it
tracks written/unwrittten/hole extent caches. When the shrinker tries
to reclaim some objects, it will scan this list and reclaim all extent
caches whose ref count are less than a number. Meanwhile the ref count
of rest caches will be decreased and moved into active list. In active
list it tracks all delayed extent caches, precached extent caches and
other caches that have been promoted. The shrinker uses LRU algorithm
to reclaim objects from active list. Please let me know if I miss
something.
Regards,
- Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
