All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Rik van Riel <riel@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Minchan Kim <minchan.kim@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH 0/3] Reduce watermark-related problems with the per-cpu allocator V2
Date: Mon, 23 Aug 2010 08:38:25 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1008230835220.5750@router.home> (raw)
In-Reply-To: <20100823130127.GP19797@csn.ul.ie>

On Mon, 23 Aug 2010, Mel Gorman wrote:

> > The maximum time for which the livelock can exists is the vm stat
> > interval. By default the counters are brought up to date at least once per
> > second or if a certain delta was violated. Drifts are controlled by the
> > delta configuration.
> >
>
> While there is a maximum time (2 seconds I think) the drift can exist
> in, a machine under enough pressure can make a mess of the watermarks
> during that time. If it wasn't the case, these livelocks with 0 pages
> free wouldn't be happening.

So because we go way beyond the watermarks we reach a state in which a
livelock exists that does not go away when the counters are finally
updated?



WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, Rik van Riel <riel@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Minchan Kim <minchan.kim@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH 0/3] Reduce watermark-related problems with the per-cpu allocator V2
Date: Mon, 23 Aug 2010 08:38:25 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1008230835220.5750@router.home> (raw)
In-Reply-To: <20100823130127.GP19797@csn.ul.ie>

On Mon, 23 Aug 2010, Mel Gorman wrote:

> > The maximum time for which the livelock can exists is the vm stat
> > interval. By default the counters are brought up to date at least once per
> > second or if a certain delta was violated. Drifts are controlled by the
> > delta configuration.
> >
>
> While there is a maximum time (2 seconds I think) the drift can exist
> in, a machine under enough pressure can make a mess of the watermarks
> during that time. If it wasn't the case, these livelocks with 0 pages
> free wouldn't be happening.

So because we go way beyond the watermarks we reach a state in which a
livelock exists that does not go away when the counters are finally
updated?


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-08-23 13:38 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-23  8:00 [PATCH 0/3] Reduce watermark-related problems with the per-cpu allocator V2 Mel Gorman
2010-08-23  8:00 ` Mel Gorman
2010-08-23  8:00 ` [PATCH 1/3] mm: page allocator: Update free page counters after pages are placed on the free list Mel Gorman
2010-08-23  8:00   ` Mel Gorman
2010-08-23 12:47   ` Christoph Lameter
2010-08-23 12:47     ` Christoph Lameter
2010-08-23  8:00 ` [PATCH 2/3] mm: page allocator: Calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake Mel Gorman
2010-08-23  8:00   ` Mel Gorman
2010-08-23 12:56   ` Christoph Lameter
2010-08-23 12:56     ` Christoph Lameter
2010-08-23 13:03     ` Mel Gorman
2010-08-23 13:03       ` Mel Gorman
2010-08-23 13:41       ` Christoph Lameter
2010-08-23 13:41         ` Christoph Lameter
2010-08-23 13:55         ` Mel Gorman
2010-08-23 13:55           ` Mel Gorman
2010-08-23 16:04           ` Christoph Lameter
2010-08-23 16:04             ` Christoph Lameter
2010-08-23 16:13             ` Mel Gorman
2010-08-23 16:13               ` Mel Gorman
2010-08-23  8:00 ` [PATCH 3/3] mm: page allocator: Drain per-cpu lists after direct reclaim allocation fails Mel Gorman
2010-08-23  8:00   ` Mel Gorman
2010-08-23 23:17   ` KOSAKI Motohiro
2010-08-23 23:17     ` KOSAKI Motohiro
2010-08-23 12:45 ` [PATCH 0/3] Reduce watermark-related problems with the per-cpu allocator V2 Christoph Lameter
2010-08-23 12:45   ` Christoph Lameter
2010-08-23 13:01   ` Mel Gorman
2010-08-23 13:01     ` Mel Gorman
2010-08-23 13:38     ` Christoph Lameter [this message]
2010-08-23 13:38       ` Christoph Lameter
2010-08-23 13:39       ` Mel Gorman
2010-08-23 13:39         ` Mel Gorman

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=alpine.DEB.2.00.1008230835220.5750@router.home \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=riel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.