linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Minchan Kim <minchan.kim@gmail.com>,
	lsf@lists.linux-foundation.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [Lsf] [LSF][MM] page allocation & direct reclaim latency
Date: Wed, 30 Mar 2011 18:49:06 +0200	[thread overview]
Message-ID: <20110330164906.GE12265@random.random> (raw)
In-Reply-To: <20110330161716.GA3876@csn.ul.ie>

Hi Mel,

On Wed, Mar 30, 2011 at 05:17:16PM +0100, Mel Gorman wrote:
> Andy Whitcroft also posted patches ages ago that were related to lumpy reclaim
> which would capture high-order pages being reclaimed for the exclusive use
> of the reclaimer. It was never shown to be necessary though. I'll read this
> thread in a bit because I'm curious to see why it came up now.

Ok ;).

About lumpy I wouldn't spend too much on lumpy, I'd rather spend on
other issues like the one you mentioned on lru ordering, and
compaction (compaction in kswapd has still an unknown solution, my
last attempt failed and we backed off to no compaction in kswapd which
is safe but doesn't help for GFP_ATOMIC order > 0).

Lumpy should go away in a few releases IIRC.

> I think we should be very wary of conflating OOM latency, reclaim latency and
> allocation latency as they are very different things with different causes.

I think it's better to stick to successful allocation latencies only
here, or at most -ENOMEM from order > 0 which normally never happens
with compaction (not the time it takes before declaring OOM and
triggering the oom killer).

> I'd prefer to see OOM-related issues treated as a separate-but-related
> problem if possible so;
> 
> 1. LRU ordering - are we aging pages properly or recycling through the
>    list too aggressively? The high_wmark*8 change made recently was
>    partially about list rotations and the associated cost so it might
>    be worth listing out whatever issues people are currently aware of.
> 2. LRU ordering - dirty pages at the end of the LRU. Are we still going
>    the right direction on this or is it still a shambles?
> 3. Compaction latency, other issues (IRQ disabling latency was the last
>    one I'm aware of)
> 4. OOM killing and OOM latency - Whole load of churn going on in there.

I prefer it too. The OOM killing is already covered in OOM topic from
Hugh, and we can add "OOM detection latency" to it.

Thanks,
Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-03-30 16:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1301373398.2590.20.camel@mulgrave.site>
2011-03-29 15:35 ` [LSF][MM] page allocation & direct reclaim latency Rik van Riel
2011-03-29 19:05   ` [Lsf] " Andrea Arcangeli
2011-03-29 20:35     ` Ying Han
2011-03-29 20:39       ` Ying Han
2011-03-29 20:45       ` Andrea Arcangeli
2011-03-29 20:53         ` Ying Han
2011-03-29 21:22     ` Rik van Riel
2011-03-29 22:38       ` Andrea Arcangeli
2011-03-29 22:13     ` Minchan Kim
2011-03-29 23:12       ` Andrea Arcangeli
2011-03-30 16:17       ` Mel Gorman
2011-03-30 16:49         ` Andrea Arcangeli [this message]
2011-03-31  0:42           ` Hugh Dickins
2011-03-31 15:15             ` Andrea Arcangeli
2011-03-31  9:30           ` Mel Gorman
2011-03-31 16:36             ` Andrea Arcangeli
2011-03-30 16:59         ` Dan Magenheimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110330164906.GE12265@random.random \
    --to=aarcange@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf@lists.linux-foundation.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).