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

[Nick Piggin]

On Wed, Oct 20, 2010 at 12:14:32PM +0900, KOSAKI Motohiro wrote:
> > On Tue, Oct 19, 2010 at 02:42:47PM +1100, npiggin@xxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/