From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ying Han <yinghan@google.com>, Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mel@csn.ul.ie>,
Rik van Riel <riel@redhat.com>, Hillf Danton <dhillf@gmail.com>,
Hugh Dickins <hughd@google.com>,
Dan Magenheimer <dan.magenheimer@oracle.com>,
linux-mm@kvack.org
Subject: Re: [PATCH V2] memcg: add mlock statistic in memory.stat
Date: Thu, 19 Apr 2012 09:59:20 +0900 [thread overview]
Message-ID: <4F8F6368.2090005@jp.fujitsu.com> (raw)
In-Reply-To: <20120418163330.ca1518c7.akpm@linux-foundation.org>
(2012/04/19 8:33), Andrew Morton wrote:
> On Wed, 18 Apr 2012 11:21:55 -0700
> Ying Han <yinghan@google.com> wrote:
>
>> We have the nr_mlock stat both in meminfo as well as vmstat system wide, this
>> patch adds the mlock field into per-memcg memory stat. The stat itself enhances
>> the metrics exported by memcg since the unevictable lru includes more than
>> mlock()'d page like SHM_LOCK'd.
>>
>> Why we need to count mlock'd pages while they are unevictable and we can not
>> do much on them anyway?
>>
>> This is true. The mlock stat I am proposing is more helpful for system admin
>> and kernel developer to understand the system workload. The same information
>> should be helpful to add into OOM log as well. Many times in the past that we
>> need to read the mlock stat from the per-container meminfo for different
>> reason. Afterall, we do have the ability to read the mlock from meminfo and
>> this patch fills the info in memcg.
>>
>>
>> ...
>>
>> static inline int is_mlocked_vma(struct vm_area_struct *vma, struct page *page)
>> {
>> + bool locked;
>> + unsigned long flags;
>> +
>> VM_BUG_ON(PageLRU(page));
>>
>> if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) != VM_LOCKED))
>> return 0;
>>
>> + mem_cgroup_begin_update_page_stat(page, &locked, &flags);
>> if (!TestSetPageMlocked(page)) {
>> inc_zone_page_state(page, NR_MLOCK);
>> + mem_cgroup_inc_page_stat(page, MEMCG_NR_MLOCK);
>> count_vm_event(UNEVICTABLE_PGMLOCKED);
>> }
>> + mem_cgroup_end_update_page_stat(page, &locked, &flags);
>> +
>> return 1;
>> }
>
> Unrelated to this patch: is_mlocked_vma() is misnamed. A function with
> that name should be a bool-returning test which has no side-effects.
>
>>
>> ...
>>
>> static void __free_pages_ok(struct page *page, unsigned int order)
>> {
>> unsigned long flags;
>> - int wasMlocked = __TestClearPageMlocked(page);
>> + bool locked;
>>
>> if (!free_pages_prepare(page, order))
>> return;
>>
>> local_irq_save(flags);
>> - if (unlikely(wasMlocked))
>> + mem_cgroup_begin_update_page_stat(page, &locked, &flags);
>
> hm, what's going on here. The page now has a zero refcount and is to
> be returned to the buddy. But mem_cgroup_begin_update_page_stat()
> assumes that the page still belongs to a memcg. I'd have thought that
> any page_cgroup backreferences would have been torn down by now?
>
>> + if (unlikely(__TestClearPageMlocked(page)))
>> free_page_mlock(page);
>
Ah, this is problem. Now, we have following code.
==
> struct lruvec *mem_cgroup_lru_add_list(struct zone *zone, struct page *page,
> enum lru_list lru)
> {
> struct mem_cgroup_per_zone *mz;
> struct mem_cgroup *memcg;
> struct page_cgroup *pc;
>
> if (mem_cgroup_disabled())
> return &zone->lruvec;
>
> pc = lookup_page_cgroup(page);
> memcg = pc->mem_cgroup;
>
> /*
> * Surreptitiously switch any uncharged page to root:
> * an uncharged page off lru does nothing to secure
> * its former mem_cgroup from sudden removal.
> *
> * Our caller holds lru_lock, and PageCgroupUsed is updated
> * under page_cgroup lock: between them, they make all uses
> * of pc->mem_cgroup safe.
> */
> if (!PageCgroupUsed(pc) && memcg != root_mem_cgroup)
> pc->mem_cgroup = memcg = root_mem_cgroup;
==
Then, accessing pc->mem_cgroup without checking PCG_USED bit is dangerous.
It may trigger #GP because of suddern removal of memcg or because of above
code, mis-accounting will happen... pc->mem_cgroup may be overwritten already.
Proposal from me is calling TestClearPageMlocked(page) via mem_cgroup_uncharge().
Like this.
==
mem_cgroup_charge_statistics(memcg, anon, -nr_pages);
/*
* Pages reach here when it's fully unmapped or dropped from file cache.
* we are under lock_page_cgroup() and have no race with memcg activities.
*/
if (unlikely(PageMlocked(page))) {
if (TestClearPageMlocked())
decrement counter.
}
ClearPageCgroupUsed(pc);
==
But please check performance impact...
Thanks,
-Kame
--
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>
next prev parent reply other threads:[~2012-04-19 1:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-18 18:21 [PATCH V2] memcg: add mlock statistic in memory.stat Ying Han
2012-04-18 23:33 ` Andrew Morton
2012-04-19 0:59 ` KAMEZAWA Hiroyuki [this message]
2012-04-19 13:12 ` Johannes Weiner
2012-04-19 22:46 ` Ying Han
2012-04-19 23:04 ` Johannes Weiner
2012-04-20 0:37 ` KAMEZAWA Hiroyuki
2012-04-20 5:57 ` Ying Han
2012-04-20 6:16 ` KAMEZAWA Hiroyuki
2012-04-20 6:39 ` Ying Han
2012-04-20 6:52 ` KAMEZAWA Hiroyuki
2012-04-19 22:43 ` Ying Han
2012-04-19 22:30 ` Ying Han
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=4F8F6368.2090005@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=dan.magenheimer@oracle.com \
--cc=dhillf@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mhocko@suse.cz \
--cc=riel@redhat.com \
--cc=yinghan@google.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.