From: Dave Hansen <dave.hansen@intel.com>
To: Greg Thelen <gthelen@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>, Tejun Heo <tj@kernel.org>,
Jens Axboe <axboe@fb.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<cgroups@vger.kernel.org>,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<linux-mm@kvack.org>, open list <linux-kernel@vger.kernel.org>
Subject: Re: 4.3-rc1 dirty page count underflow (cgroup-related?)
Date: Fri, 18 Sep 2015 07:50:42 -0700 [thread overview]
Message-ID: <55FC24C2.8020501@intel.com> (raw)
In-Reply-To: <xr938u84ntrn.fsf@gthelen.mtv.corp.google.com>
On 09/17/2015 11:09 PM, Greg Thelen wrote:
> I'm not denying the issue, bug the WARNING splat isn't necessarily
> catching a problem. The corresponding code comes from your debug patch:
> + WARN_ONCE(__this_cpu_read(memcg->stat->count[MEM_CGROUP_STAT_DIRTY]) > (1UL<<30), "MEM_CGROUP_STAT_DIRTY bogus");
>
> This only checks a single cpu's counter, which can be negative. The sum
> of all counters is what matters.
> Imagine:
> cpu1) dirty page: inc
> cpu2) clean page: dec
> The sum is properly zero, but cpu2 is -1, which will trigger the WARN.
>
> I'll look at the code and also see if I can reproduce the failure using
> mem_cgroup_read_stat() for all of the new WARNs.
D'oh. I'll replace those with the proper mem_cgroup_read_stat() and
test with your patch to see if anything still triggers.
> Did you notice if the global /proc/meminfo:Dirty count also underflowed?
It did not underflow. It was one of the first things I looked at and it
looked fine, went down near 0 at 'sync', etc...
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.com>
To: Greg Thelen <gthelen@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>, Tejun Heo <tj@kernel.org>,
Jens Axboe <axboe@fb.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<cgroups@vger.kernel.org>,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<linux-mm@kvack.org>, open list <linux-kernel@vger.kernel.org>
Subject: Re: 4.3-rc1 dirty page count underflow (cgroup-related?)
Date: Fri, 18 Sep 2015 07:50:42 -0700 [thread overview]
Message-ID: <55FC24C2.8020501@intel.com> (raw)
In-Reply-To: <xr938u84ntrn.fsf@gthelen.mtv.corp.google.com>
On 09/17/2015 11:09 PM, Greg Thelen wrote:
> I'm not denying the issue, bug the WARNING splat isn't necessarily
> catching a problem. The corresponding code comes from your debug patch:
> + WARN_ONCE(__this_cpu_read(memcg->stat->count[MEM_CGROUP_STAT_DIRTY]) > (1UL<<30), "MEM_CGROUP_STAT_DIRTY bogus");
>
> This only checks a single cpu's counter, which can be negative. The sum
> of all counters is what matters.
> Imagine:
> cpu1) dirty page: inc
> cpu2) clean page: dec
> The sum is properly zero, but cpu2 is -1, which will trigger the WARN.
>
> I'll look at the code and also see if I can reproduce the failure using
> mem_cgroup_read_stat() for all of the new WARNs.
D'oh. I'll replace those with the proper mem_cgroup_read_stat() and
test with your patch to see if anything still triggers.
> Did you notice if the global /proc/meminfo:Dirty count also underflowed?
It did not underflow. It was one of the first things I looked at and it
looked fine, went down near 0 at 'sync', etc...
next prev parent reply other threads:[~2015-09-18 14:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 4:29 4.3-rc1 dirty page count underflow (cgroup-related?) Dave Hansen
2015-09-18 4:29 ` Dave Hansen
[not found] ` <55FB9319.2010000-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-09-18 6:09 ` Greg Thelen
2015-09-18 6:09 ` Greg Thelen
2015-09-18 6:09 ` Greg Thelen
2015-09-18 8:31 ` Greg Thelen
2015-09-18 8:31 ` Greg Thelen
2015-09-18 8:31 ` Greg Thelen
2015-09-18 14:50 ` Dave Hansen [this message]
2015-09-18 14:50 ` Dave Hansen
[not found] ` <55FC24C2.8020501-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-09-21 8:06 ` Greg Thelen
2015-09-21 8:06 ` Greg Thelen
2015-09-21 8:06 ` Greg Thelen
2015-09-22 9:03 ` Michal Hocko
2015-09-22 9:03 ` Michal Hocko
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=55FC24C2.8020501@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@fb.com \
--cc=cgroups@vger.kernel.org \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=tj@kernel.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.