Re: vmscan: Do not run shrinkers for zones other than ZONE_NORMAL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 21 Oct 2010, Andrew Morton wrote:

> The patch doesn't patch direct reclaim, in do_try_to_free_pages().  How
> come?

Direct reclaim does not run node specific shrink_slab. Direct reclaim does
a general pass after the individual zones have been shrunk.

> OK, maybe this.  Suppose we have a machine with 800M lowmem and 200M
> highmem.  And suppose the lowmem region is stuffed full of clean
> icache/dcache.  A __GFP_HIGHMEM allocation should put pressure on
> lowmem to get some of those pages back.  What we don't want to do is to
> keep on reclaiming the highmem zone and allocating pages from there,
> because the machine would effectively end up with only 200M available
> for pagecache.

Shrinker reclaim is not zone specific. It either occurs on a node or on
the system as a whole. A failure of HIGHMEM allocation in the direct
reclaim path will result in shrinkers being called with NO_NUMA_NODE and
therefore global reclaim will take place everywhere.

Per node reclaim occurs from kswapd and covers all zones of that node.

> Please convince us that your patch doesn't screw up zone balancing?

There are no slab allocations in HIGHMEM or MOVABLE. Nothing to balance
there.

That reminds me: We also have counters on how many slabs exist in a given
zone these days. We could check for zero there and just not run the
shrinkers if zero. We could also use those counters to guide shrink_slab
in a better way.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]