[lkml]   [2009]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit
On Fri, 23 Oct 2009, Mel Gorman wrote:

> > Hmm, is this really supposed to be added to __alloc_pages_high_priority()?
> > By the patch description I was expecting kswapd to be woken up
> > preemptively whenever the preferred zone is below ALLOC_WMARK_LOW and
> > we're known to have just allocated at a higher order, not just when
> > current was oom killed (when we should already be freeing a _lot_ of
> > memory soon) or is doing a higher order allocation during direct reclaim.
> >
> It was a somewhat arbitrary choice to have it trigger in the event high
> priority allocations were happening frequently.

I don't quite understand, users of PF_MEMALLOC shouldn't be doing these
higher order allocations and if ALLOC_NO_WATERMARKS is by way of the oom
killer, we should be freeing a substantial amount of memory imminently
when it exits that waking up kswapd would be irrelevant.

> > If this is moved to the fastpath, why is this wake_all_kswapd() and not
> > wakeup_kswapd(preferred_zone, order)? Do we need to kick kswapd in all
> > zones even though they may be free just because preferred_zone is now
> > below the watermark?
> >
> It probably makes no difference as zones are checked for their watermarks
> before any real work happens. However, even if this patch makes a difference,
> I don't want to see it merged. At best, it is an extremely heavy-handed
> hack which is why I asked for it to be tested in isolation. It shouldn't
> be necessary at all because sort of pre-emptive waking of kswapd was never
> necessary before.

Ahh, that makes a ton more sense: this particular patch is a debugging
effort while the first two are candidates for 2.6.32 and -stable. Gotcha.

> > Wouldn't it be better to do this on page_zone(page) instead of
> > preferred_zone anyway?
> >
> No. The preferred_zone is the zone we should be allocating from. If we
> failed to allocate from it, it implies the watermarks are not being met
> so we want to wake it.

Oops, I'm even more confused now :) I thought the existing
wake_all_kswapd() in the slowpath was doing that and that this patch was
waking them prematurely because it speculates that a subsequent high
order allocation will fail unless memory is reclaimed. I thought we'd
want to reclaim from the zone we just did a high order allocation from so
that the fastpath could find the memory next time with ALLOC_WMARK_LOW.

 \ /
  Last update: 2009-10-23 11:39    [W:0.038 / U:3.972 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site