From: Balbir Singh <balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Subject: Re: [PATCH 6/6 mm] memcgroup: revert swap_state mods
Date: Mon, 12 Nov 2007 12:26:04 +0530 [thread overview]
Message-ID: <4737F904.8080107@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0711090713300.21663-VFT1Jj/mpSzq8/QPP7pA5326JSxr+BKB@public.gmane.org>
Hugh Dickins wrote:
> If we're charging rss and we're charging cache, it seems obvious that
> we should be charging swapcache - as has been done. But in practice
> that doesn't work out so well: both swapin readahead and swapoff leave
> the majority of pages charged to the wrong cgroup (the cgroup that
> happened to read them in, rather than the cgroup to which they belong).
>
> (Which is why unuse_pte's GFP_KERNEL while holding pte lock never
> showed up as a problem: no allocation was ever done there, every page
> read being already charged to the cgroup which initiated the swapoff.)
>
> It all works rather better if we leave the charging to do_swap_page and
> unuse_pte, and do nothing for swapcache itself: revert mm/swap_state.c
> to what it was before the memory-controller patches. This also speeds
> up significantly a contained process working at its limit: because it
> no longer needs to keep waiting for swap writeback to complete.
>
Yes, it does speed up things, but we lose control over swap cache.
It might grow very large, but having said that I am in favour of
removing the mods till someone faces a severe problem with them.
Another approach is to provide a per-container tunable as to
whether swap cache should be controlled or not and document
the side-effects of swap cache control.
> Is it unfair that swap pages become uncharged once they're unmapped,
> even though they're still clearly private to particular cgroups? For
> a short while, yes; but PageReclaim arranges for those pages to go to
> the end of the inactive list and be reclaimed soon if necessary.
>
> shmem/tmpfs pages are a distinct case: their charging also benefits
> from this change, but their second life on the lists as swapcache
> pages may prove more unfair - that I need to check next.
>
> Signed-off-by: Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Thanks for the patch
Acked-by: Balbir Singh <balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org, containers@lists.osdl.org
Subject: Re: [PATCH 6/6 mm] memcgroup: revert swap_state mods
Date: Mon, 12 Nov 2007 12:26:04 +0530 [thread overview]
Message-ID: <4737F904.8080107@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0711090713300.21663@blonde.wat.veritas.com>
Hugh Dickins wrote:
> If we're charging rss and we're charging cache, it seems obvious that
> we should be charging swapcache - as has been done. But in practice
> that doesn't work out so well: both swapin readahead and swapoff leave
> the majority of pages charged to the wrong cgroup (the cgroup that
> happened to read them in, rather than the cgroup to which they belong).
>
> (Which is why unuse_pte's GFP_KERNEL while holding pte lock never
> showed up as a problem: no allocation was ever done there, every page
> read being already charged to the cgroup which initiated the swapoff.)
>
> It all works rather better if we leave the charging to do_swap_page and
> unuse_pte, and do nothing for swapcache itself: revert mm/swap_state.c
> to what it was before the memory-controller patches. This also speeds
> up significantly a contained process working at its limit: because it
> no longer needs to keep waiting for swap writeback to complete.
>
Yes, it does speed up things, but we lose control over swap cache.
It might grow very large, but having said that I am in favour of
removing the mods till someone faces a severe problem with them.
Another approach is to provide a per-container tunable as to
whether swap cache should be controlled or not and document
the side-effects of swap cache control.
> Is it unfair that swap pages become uncharged once they're unmapped,
> even though they're still clearly private to particular cgroups? For
> a short while, yes; but PageReclaim arranges for those pages to go to
> the end of the inactive list and be reclaimed soon if necessary.
>
> shmem/tmpfs pages are a distinct case: their charging also benefits
> from this change, but their second life on the lists as swapcache
> pages may prove more unfair - that I need to check next.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
Thanks for the patch
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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>
next prev parent reply other threads:[~2007-11-12 6:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-09 7:08 [PATCH 1/6 mm] swapoff: scan ptes preemptibly Hugh Dickins
2007-11-09 7:08 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0711090700530.21638-VFT1Jj/mpSzq8/QPP7pA5326JSxr+BKB@public.gmane.org>
2007-11-09 7:10 ` [PATCH 2/6 mm] memcgroup: temporarily revert swapoff mod Hugh Dickins
2007-11-09 7:10 ` Hugh Dickins
2007-11-09 7:11 ` [PATCH 3/6 mm] memcgroup: fix try_to_free order Hugh Dickins
2007-11-09 7:11 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0711090710310.21663-VFT1Jj/mpSzq8/QPP7pA5326JSxr+BKB@public.gmane.org>
2007-11-12 5:05 ` Balbir Singh
2007-11-12 5:05 ` Balbir Singh
2007-11-09 7:12 ` [PATCH 4/6 mm] memcgroup: reinstate swapoff mod Hugh Dickins
2007-11-09 7:12 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0711090711190.21663-VFT1Jj/mpSzq8/QPP7pA5326JSxr+BKB@public.gmane.org>
2007-11-12 5:08 ` Balbir Singh
2007-11-12 5:08 ` Balbir Singh
2007-11-09 7:13 ` [PATCH 5/6 mm] memcgroup: fix zone isolation OOM Hugh Dickins
2007-11-09 7:13 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0711090712180.21663-VFT1Jj/mpSzq8/QPP7pA5326JSxr+BKB@public.gmane.org>
2007-11-09 9:27 ` KAMEZAWA Hiroyuki
2007-11-09 9:27 ` KAMEZAWA Hiroyuki
2007-11-12 6:42 ` Balbir Singh
2007-11-12 6:42 ` Balbir Singh
2007-11-09 7:14 ` [PATCH 6/6 mm] memcgroup: revert swap_state mods Hugh Dickins
2007-11-09 7:14 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0711090713300.21663-VFT1Jj/mpSzq8/QPP7pA5326JSxr+BKB@public.gmane.org>
2007-11-09 9:21 ` KAMEZAWA Hiroyuki
2007-11-09 9:21 ` KAMEZAWA Hiroyuki
[not found] ` <20071109182156.7174e92b.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-11-12 4:57 ` Hugh Dickins
2007-11-12 4:57 ` Hugh Dickins
[not found] ` <Pine.LNX.4.64.0711120447010.23491-VFT1Jj/mpSzq8/QPP7pA5326JSxr+BKB@public.gmane.org>
2007-11-12 5:17 ` KAMEZAWA Hiroyuki
2007-11-12 5:17 ` KAMEZAWA Hiroyuki
2007-11-12 6:56 ` Balbir Singh [this message]
2007-11-12 6:56 ` Balbir Singh
2007-11-12 5:04 ` [PATCH 1/6 mm] swapoff: scan ptes preemptibly Balbir Singh
2007-11-12 5:04 ` Balbir Singh
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=4737F904.8080107@linux.vnet.ibm.com \
--to=balbir-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@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.