linux-kernel - Re: [patch 31/35] fs: icache per-zone inode LRU

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:	Wed, 20 Oct 2010 14:20:24 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Dave Chinner <david@...morbit.com>, npiggin@...nel.dk,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [patch 31/35] fs: icache per-zone inode LRU

On Wed, Oct 20, 2010 at 12:14:32PM +0900, KOSAKI Motohiro wrote:
> > On Tue, Oct 19, 2010 at 02:42:47PM +1100, npiggin@...nel.dk wrote:
> > Anyway, my main point is that tying the LRU and shrinker scaling to
> > the implementation of the VM is a one-off solution that doesn't work
> > for generic infrastructure. Other subsystems need the same
> > large-machine scaling treatment, and there's no way we should be
> > tying them all into the struct zone. It needs further abstraction.
> 
> I'm not sure what data structure is best. I can only say current
> zone unawareness slab shrinker might makes following sad scenario.
> 
>  o DMA zone shortage invoke and plenty icache in NORMAL zone dropping
>  o NUMA aware system enable zone_reclaim_mode, but shrink_slab() still
>    drop unrelated zone's icache
> 
> both makes performance degression. In other words, Linux does not have
> flat memory model. so, I don't think Nick's basic concept is wrong. 
> It's straight forward enhancement. but if it don't fit current shrinkers,
> I'd like to discuss how to make better data structure.
> 
> 
> 
> and I have dump question (sorry, I don't know xfs at all). current
> xfs_mount is below.
> 
> typedef struct xfs_mount {
>  ...
>         struct shrinker         m_inode_shrink; /* inode reclaim shrinker */
> } xfs_mount_t;
> 
> 
> Do you mean xfs can't convert shrinker to shrinker[ZONES]? If so, why?

Well if XFS were to use per-ZONE shrinkers, it would remain with a
single shrinker context per-sb like it has now, but it would divide
its object management into per-zone structures.

For subsystems that aren't important, don't take much memory or have
much reclaim throughput, they are free to ignore the zone argument
and keep using the global input to the shrinker.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/