All of lore.kernel.org
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Rientjes <rientjes@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memcg,thp: fix res_counter:96 regression
Date: Mon, 21 May 2012 19:26:09 +0900	[thread overview]
Message-ID: <4FBA1841.40506@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1205181116160.2082@eggly.anvils>

(2012/05/19 3:28), Hugh Dickins wrote:

> Occasionally, testing memcg's move_charge_at_immigrate on rc7 shows
> a flurry of hundreds of warnings at kernel/res_counter.c:96, where
> res_counter_uncharge_locked() does WARN_ON(counter->usage < val).
> 
> The first trace of each flurry implicates __mem_cgroup_cancel_charge()
> of mc.precharge, and an audit of mc.precharge handling points to
> mem_cgroup_move_charge_pte_range()'s THP handling in 12724850e806
> "memcg: avoid THP split in task migration".
> 
> Checking !mc.precharge is good everywhere else, when a single page is
> to be charged; but here the "mc.precharge -= HPAGE_PMD_NR" likely to
> follow, is liable to result in underflow (a lot can change since the
> precharge was estimated).
> 
> Simply check against HPAGE_PMD_NR: there's probably a better alternative,
> trying precharge for more, splitting if unsuccessful; but this one-liner
> is safer for now - no kernel/res_counter.c:96 warnings seen in 26 hours.
> 
> Signed-off-by: Hugh Dickins <hughd@google.com>


Thank you.

Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>



--
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>

WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Rientjes <rientjes@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memcg,thp: fix res_counter:96 regression
Date: Mon, 21 May 2012 19:26:09 +0900	[thread overview]
Message-ID: <4FBA1841.40506@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1205181116160.2082@eggly.anvils>

(2012/05/19 3:28), Hugh Dickins wrote:

> Occasionally, testing memcg's move_charge_at_immigrate on rc7 shows
> a flurry of hundreds of warnings at kernel/res_counter.c:96, where
> res_counter_uncharge_locked() does WARN_ON(counter->usage < val).
> 
> The first trace of each flurry implicates __mem_cgroup_cancel_charge()
> of mc.precharge, and an audit of mc.precharge handling points to
> mem_cgroup_move_charge_pte_range()'s THP handling in 12724850e806
> "memcg: avoid THP split in task migration".
> 
> Checking !mc.precharge is good everywhere else, when a single page is
> to be charged; but here the "mc.precharge -= HPAGE_PMD_NR" likely to
> follow, is liable to result in underflow (a lot can change since the
> precharge was estimated).
> 
> Simply check against HPAGE_PMD_NR: there's probably a better alternative,
> trying precharge for more, splitting if unsuccessful; but this one-liner
> is safer for now - no kernel/res_counter.c:96 warnings seen in 26 hours.
> 
> Signed-off-by: Hugh Dickins <hughd@google.com>


Thank you.

Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>




  reply	other threads:[~2012-05-21 10:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 18:28 [PATCH] memcg,thp: fix res_counter:96 regression Hugh Dickins
2012-05-18 18:28 ` Hugh Dickins
2012-05-21 10:26 ` KAMEZAWA Hiroyuki [this message]
2012-05-21 10:26   ` KAMEZAWA Hiroyuki

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=4FBA1841.40506@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    /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.