lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 21 Apr 2014 22:46:46 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org, Zheng Liu <wenqing.lz@...bao.com>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Jan Kara <jack@...e.cz>
Subject: Re: [RFC PATCH v2 0/4] ext4: extents status tree shrinker improvement

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ