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:34:49 +0800 [thread overview]
Message-ID: <4F2601C9.6000606@cn.fujitsu.com> (raw)
In-Reply-To: <20120103160411.GD3891-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
Michal Hocko said the following on 2012-1-4 0:04:
> On Wed 28-12-11 17:23:04, Peng Haitao wrote:
>>
>> memory.memsw.failcnt shows the number of memory+Swap hits limits.
>> So I think when memory+swap usage is equal to limit, memsw.failcnt should be nonzero.
>>
>> I test as follows:
>>
>> # uname -a
>> Linux K-test 3.2.0-rc7-17-g371de6e #2 SMP Wed Dec 28 12:02:52 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
>> # mkdir /cgroup/memory/group
>> # cd /cgroup/memory/group/
>> # echo 10M > memory.limit_in_bytes
>> # echo 10M > memory.memsw.limit_in_bytes
>> # echo $$ > tasks
>> # dd if=/dev/zero of=/tmp/temp_file count=20 bs=1M
>> Killed
>> # cat memory.memsw.failcnt
>> 0
>> # grep "failcnt" /var/log/messages | tail -2
>> Dec 28 17:05:52 K-test kernel: memory: usage 10240kB, limit 10240kB, failcnt 21
>> Dec 28 17:05:52 K-test kernel: memory+swap: usage 10240kB, limit 10240kB, failcnt 0
>>
>> memory+swap usage is equal to limit, but memsw.failcnt is zero.
>>
> Please note that memsw.limit_in_bytes is triggered only if we have
> consumed some swap space already (and the feature is primarily intended
> to stop extensive swap usage in fact).
> It goes like this: If we trigger hard limit (memory.limit_in_bytes) then
> we start the direct reclaim (with swap available). If we trigger memsw
> limit then we try to reclaim without swap available. We will OOM if we
> cannot reclaim enough to satisfy the respective limit.
>
> The other part of the answer is, yes there is something wrong going
> on her because we definitely shouldn't OOM. The workload is a single
> threaded and we have a plenty of page cache that could be reclaimed
> easily. On the other hand we end up with:
> # echo $$ > tasks
> /dev/memctl/a# echo 10M > memory.limit_in_bytes
> /dev/memctl/a# echo 10M > memory.memsw.limit_in_bytes
> /dev/memctl/a# dd if=/dev/zero of=/tmp/temp_file count=20 bs=1M
> Killed
> /dev/memctl/a# cat memory.stat
> cache 9265152
> [...]
>
> So there is almost 10M of page cache that we can simply reclaim. If we
> use 40M limit then we are OK. So this looks like the small limit somehow
> tricks our math in the reclaim path and we think there is nothing to
> reclaim.
> I will look into this.
Have any conclusion for this?
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:34:49 +0800 [thread overview]
Message-ID: <4F2601C9.6000606@cn.fujitsu.com> (raw)
In-Reply-To: <20120103160411.GD3891@tiehlicka.suse.cz>
Michal Hocko said the following on 2012-1-4 0:04:
> On Wed 28-12-11 17:23:04, Peng Haitao wrote:
>>
>> memory.memsw.failcnt shows the number of memory+Swap hits limits.
>> So I think when memory+swap usage is equal to limit, memsw.failcnt should be nonzero.
>>
>> I test as follows:
>>
>> # uname -a
>> Linux K-test 3.2.0-rc7-17-g371de6e #2 SMP Wed Dec 28 12:02:52 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
>> # mkdir /cgroup/memory/group
>> # cd /cgroup/memory/group/
>> # echo 10M > memory.limit_in_bytes
>> # echo 10M > memory.memsw.limit_in_bytes
>> # echo $$ > tasks
>> # dd if=/dev/zero of=/tmp/temp_file count=20 bs=1M
>> Killed
>> # cat memory.memsw.failcnt
>> 0
>> # grep "failcnt" /var/log/messages | tail -2
>> Dec 28 17:05:52 K-test kernel: memory: usage 10240kB, limit 10240kB, failcnt 21
>> Dec 28 17:05:52 K-test kernel: memory+swap: usage 10240kB, limit 10240kB, failcnt 0
>>
>> memory+swap usage is equal to limit, but memsw.failcnt is zero.
>>
> Please note that memsw.limit_in_bytes is triggered only if we have
> consumed some swap space already (and the feature is primarily intended
> to stop extensive swap usage in fact).
> It goes like this: If we trigger hard limit (memory.limit_in_bytes) then
> we start the direct reclaim (with swap available). If we trigger memsw
> limit then we try to reclaim without swap available. We will OOM if we
> cannot reclaim enough to satisfy the respective limit.
>
> The other part of the answer is, yes there is something wrong going
> on her because we definitely shouldn't OOM. The workload is a single
> threaded and we have a plenty of page cache that could be reclaimed
> easily. On the other hand we end up with:
> # echo $$ > tasks
> /dev/memctl/a# echo 10M > memory.limit_in_bytes
> /dev/memctl/a# echo 10M > memory.memsw.limit_in_bytes
> /dev/memctl/a# dd if=/dev/zero of=/tmp/temp_file count=20 bs=1M
> Killed
> /dev/memctl/a# cat memory.stat
> cache 9265152
> [...]
>
> So there is almost 10M of page cache that we can simply reclaim. If we
> use 40M limit then we are OK. So this looks like the small limit somehow
> tricks our math in the reclaim path and we think there is nothing to
> reclaim.
> I will look into this.
Have any conclusion for this?
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:34:49 +0800 [thread overview]
Message-ID: <4F2601C9.6000606@cn.fujitsu.com> (raw)
In-Reply-To: <20120103160411.GD3891@tiehlicka.suse.cz>
Michal Hocko said the following on 2012-1-4 0:04:
> On Wed 28-12-11 17:23:04, Peng Haitao wrote:
>>
>> memory.memsw.failcnt shows the number of memory+Swap hits limits.
>> So I think when memory+swap usage is equal to limit, memsw.failcnt should be nonzero.
>>
>> I test as follows:
>>
>> # uname -a
>> Linux K-test 3.2.0-rc7-17-g371de6e #2 SMP Wed Dec 28 12:02:52 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
>> # mkdir /cgroup/memory/group
>> # cd /cgroup/memory/group/
>> # echo 10M > memory.limit_in_bytes
>> # echo 10M > memory.memsw.limit_in_bytes
>> # echo $$ > tasks
>> # dd if=/dev/zero of=/tmp/temp_file count=20 bs=1M
>> Killed
>> # cat memory.memsw.failcnt
>> 0
>> # grep "failcnt" /var/log/messages | tail -2
>> Dec 28 17:05:52 K-test kernel: memory: usage 10240kB, limit 10240kB, failcnt 21
>> Dec 28 17:05:52 K-test kernel: memory+swap: usage 10240kB, limit 10240kB, failcnt 0
>>
>> memory+swap usage is equal to limit, but memsw.failcnt is zero.
>>
> Please note that memsw.limit_in_bytes is triggered only if we have
> consumed some swap space already (and the feature is primarily intended
> to stop extensive swap usage in fact).
> It goes like this: If we trigger hard limit (memory.limit_in_bytes) then
> we start the direct reclaim (with swap available). If we trigger memsw
> limit then we try to reclaim without swap available. We will OOM if we
> cannot reclaim enough to satisfy the respective limit.
>
> The other part of the answer is, yes there is something wrong going
> on her because we definitely shouldn't OOM. The workload is a single
> threaded and we have a plenty of page cache that could be reclaimed
> easily. On the other hand we end up with:
> # echo $$ > tasks
> /dev/memctl/a# echo 10M > memory.limit_in_bytes
> /dev/memctl/a# echo 10M > memory.memsw.limit_in_bytes
> /dev/memctl/a# dd if=/dev/zero of=/tmp/temp_file count=20 bs=1M
> Killed
> /dev/memctl/a# cat memory.stat
> cache 9265152
> [...]
>
> So there is almost 10M of page cache that we can simply reclaim. If we
> use 40M limit then we are OK. So this looks like the small limit somehow
> tricks our math in the reclaim path and we think there is nothing to
> reclaim.
> I will look into this.
Have any conclusion for this?
Thanks.
--
Best Regards,
Peng
next prev parent reply other threads:[~2012-01-30 2:34 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
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 [this message]
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=4F2601C9.6000606@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.