Re: [RFC] Remove temp_priority

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

 



Martin Bligh wrote:
Nick Piggin wrote:

For that matter (going off the topic a bit), I wonder if
try_to_free_pages should have a watermark check there too? This
might help reduce the latency issue you brought up where one process
has reclaimed a lot of pages, but another isn't making any progress
and has to go through the full priority range? Maybe that's
statistically pretty unlikely?


I've been mulling over how to kill prev_priority (and make everyone
happy, including akpm). My original thought was to keep a different
min_priority for each of GFP_IO, GFP_IO|GFP_FS, and the no IO ones.
But we still have the problem of how to accurately set the min back
up when we are sucessful.

Perhaps we should be a little more radical, and treat everyone apart
from kswapd as independant. Keep a kswapd_priority in the zone
structure, and all the direct reclaimers have their own local priority.
Then we set distress from min(kswap_priority, priority). All that does
is kick the direct reclaimers up a bit faster - kswapd has the easiest
time reclaiming pages, so that should never be too low.

I think that could *work*, but I still think it is a heuristics change
rather than a bug fix.

Do we want everyone to make some progress, even if that means having
some do some swapping and others not; or have the zone pressure (and
tendancy to swap) depend on how well progress is going, globally?

The latter is what we have now, and I don't think it is terrible (not
saying your idea can't work better, but it would need careful
consideration).

Coming from another angle, I am thinking about doing away with direct
reclaim completely. That means we don't need any GFP_IO or GFP_FS, and
solves the problem of large numbers of processes stuck in reclaim and
skewing aging and depleting the memory reserve.

But that's tricky because we don't have enough kswapds to get maximum
reclaim throughput on many configurations (only single core opterons
and UP systems, really).

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux