All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peng Haitao <penght-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: how to make memory.memsw.failcnt is nonzero
Date: Mon, 30 Jan 2012 10:47:33 +0800	[thread overview]
Message-ID: <4F2604C5.7050900@cn.fujitsu.com> (raw)
In-Reply-To: <20120106101219.GB10292-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>


Michal Hocko said the following on 2012-1-6 18:12:
>> If there is something wrong, I think the bug will be in mem_cgroup_do_charge()
>> of mm/memcontrol.c
>>
>> 2210         ret = res_counter_charge(&memcg->res, csize, &fail_res);
>> 2211 
>> 2212         if (likely(!ret)) {
...
>> 2221                 flags |= MEM_CGROUP_RECLAIM_NOSWAP;
>> 2222         } else
>> 2223                 mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);
>>
>> When hit memory.limit_in_bytes, res_counter_charge() will return -ENOMEM,
>> this will execute line 2222: } else.
>> But I think when hit memory.limit_in_bytes, the function should determine further
>> to memory.memsw.limit_in_bytes.
>> This think is OK?
> 
> I don't think so. We have an invariant (hard limit is "stronger" than
> memsw limit) memory.limit_in_bytes <= memory.memsw.limit_in_bytes so
> when we hit the hard limit we do not have to consider memsw because
> resource counter:
>  a) we already have to do reclaim for hard limit
>  b) we check whether we might swap out later on in
>  mem_cgroup_hierarchical_reclaim (root_memcg->memsw_is_minimum) so we
>  will not end up swapping just to make hard limit ok and go over memsw
>  limit.
> 
> Please also note that we will retry charging after reclaim if there is a
> chance to meet the limit.
> Makes sense?

Yeah.

But I want to test memory.memsw.failcnt is nonzero, how steps?
Thanks.

-- 
Best Regards,
Peng

WARNING: multiple messages have this Message-ID (diff)
From: Peng Haitao <penght@cn.fujitsu.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: how to make memory.memsw.failcnt is nonzero
Date: Mon, 30 Jan 2012 10:47:33 +0800	[thread overview]
Message-ID: <4F2604C5.7050900@cn.fujitsu.com> (raw)
In-Reply-To: <20120106101219.GB10292@tiehlicka.suse.cz>


Michal Hocko said the following on 2012-1-6 18:12:
>> If there is something wrong, I think the bug will be in mem_cgroup_do_charge()
>> of mm/memcontrol.c
>>
>> 2210         ret = res_counter_charge(&memcg->res, csize, &fail_res);
>> 2211 
>> 2212         if (likely(!ret)) {
...
>> 2221                 flags |= MEM_CGROUP_RECLAIM_NOSWAP;
>> 2222         } else
>> 2223                 mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);
>>
>> When hit memory.limit_in_bytes, res_counter_charge() will return -ENOMEM,
>> this will execute line 2222: } else.
>> But I think when hit memory.limit_in_bytes, the function should determine further
>> to memory.memsw.limit_in_bytes.
>> This think is OK?
> 
> I don't think so. We have an invariant (hard limit is "stronger" than
> memsw limit) memory.limit_in_bytes <= memory.memsw.limit_in_bytes so
> when we hit the hard limit we do not have to consider memsw because
> resource counter:
>  a) we already have to do reclaim for hard limit
>  b) we check whether we might swap out later on in
>  mem_cgroup_hierarchical_reclaim (root_memcg->memsw_is_minimum) so we
>  will not end up swapping just to make hard limit ok and go over memsw
>  limit.
> 
> Please also note that we will retry charging after reclaim if there is a
> chance to meet the limit.
> Makes sense?

Yeah.

But I want to test memory.memsw.failcnt is nonzero, how steps?
Thanks.

-- 
Best Regards,
Peng

--
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: Peng Haitao <penght@cn.fujitsu.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: how to make memory.memsw.failcnt is nonzero
Date: Mon, 30 Jan 2012 10:47:33 +0800	[thread overview]
Message-ID: <4F2604C5.7050900@cn.fujitsu.com> (raw)
In-Reply-To: <20120106101219.GB10292@tiehlicka.suse.cz>


Michal Hocko said the following on 2012-1-6 18:12:
>> If there is something wrong, I think the bug will be in mem_cgroup_do_charge()
>> of mm/memcontrol.c
>>
>> 2210         ret = res_counter_charge(&memcg->res, csize, &fail_res);
>> 2211 
>> 2212         if (likely(!ret)) {
...
>> 2221                 flags |= MEM_CGROUP_RECLAIM_NOSWAP;
>> 2222         } else
>> 2223                 mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);
>>
>> When hit memory.limit_in_bytes, res_counter_charge() will return -ENOMEM,
>> this will execute line 2222: } else.
>> But I think when hit memory.limit_in_bytes, the function should determine further
>> to memory.memsw.limit_in_bytes.
>> This think is OK?
> 
> I don't think so. We have an invariant (hard limit is "stronger" than
> memsw limit) memory.limit_in_bytes <= memory.memsw.limit_in_bytes so
> when we hit the hard limit we do not have to consider memsw because
> resource counter:
>  a) we already have to do reclaim for hard limit
>  b) we check whether we might swap out later on in
>  mem_cgroup_hierarchical_reclaim (root_memcg->memsw_is_minimum) so we
>  will not end up swapping just to make hard limit ok and go over memsw
>  limit.
> 
> Please also note that we will retry charging after reclaim if there is a
> chance to meet the limit.
> Makes sense?

Yeah.

But I want to test memory.memsw.failcnt is nonzero, how steps?
Thanks.

-- 
Best Regards,
Peng


  parent reply	other threads:[~2012-01-30  2:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-28  9:23 how to make memory.memsw.failcnt is nonzero Peng Haitao
     [not found] ` <4EFADFF8.5020703-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-01-03 16:04   ` Michal Hocko
2012-01-03 16:04     ` Michal Hocko
2012-01-03 16:04     ` Michal Hocko
     [not found]     ` <20120103160411.GD3891-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-06  9:47       ` Peng Haitao
2012-01-06  9:47         ` Peng Haitao
2012-01-06  9:47         ` Peng Haitao
2012-01-06 10:12         ` Michal Hocko
2012-01-06 10:12           ` Michal Hocko
     [not found]           ` <20120106101219.GB10292-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-30  2:47             ` Peng Haitao [this message]
2012-01-30  2:47               ` Peng Haitao
2012-01-30  2:47               ` Peng Haitao
     [not found]               ` <4F2604C5.7050900-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-01-30  7:24                 ` KAMEZAWA Hiroyuki
2012-01-30  7:24                   ` KAMEZAWA Hiroyuki
2012-01-30  7:24                   ` KAMEZAWA Hiroyuki
2012-01-30  2:34       ` Peng Haitao
2012-01-30  2:34         ` Peng Haitao
2012-01-30  2:34         ` Peng Haitao
2012-01-30  8:46         ` Michal Hocko
2012-01-30  8:46           ` 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=4F2604C5.7050900@cn.fujitsu.com \
    --to=penght-bthxqxjhjhxqfuhtdcdx3a@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mhocko-AlSwsSmVLrQ@public.gmane.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.