On Tue, 18 Sep 2007, J. Bruce Fields wrote:
On Tue, Sep 18, 2007 at 12:54:56PM -0400, Trond Myklebust wrote:
It gets even better when you throw mmap() into the mix :-)
Hm. Documentation/mandatory.txt claims that it mandatory locks and
mmap() with MAP_SHARED exclude each other, but I
On Fri, 5 Oct 2007, Balbir Singh wrote:
Found-by: Hugh Dickins [EMAIL PROTECTED]
mem_cgroup_charge() in unuse_pte() is called under a lock, the pte_lock.
That's
clearly incorrect, since we pass GFP_KERNEL to mem_cgroup_charge() for
allocation of page_cgroup.
This patch release
On Mon, 15 Oct 2007, Balbir Singh wrote:
Hugh Dickins wrote:
--- 2.6.23-rc8-mm2/mm/swapfile.c2007-09-27 12:03:36.0 +0100
+++ linux/mm/swapfile.c 2007-10-07 14:33:05.0 +0100
@@ -507,11 +507,23 @@ unsigned int count_swap_pages(int type,
* just let do_wp_page
On Wed, 24 Oct 2007, Balbir Singh wrote:
Hugh Dickins wrote:
Thanks, Balbir. Sorry for the delay. I've not forgotten our
agreement that I should be splitting it into before-and-after
mem cgroup patches. But it's low priority for me until we're
genuinely assigning to a cgroup
On Mon, 29 Oct 2007, Balbir Singh wrote:
On Mon, Oct 29, 2007 at 01:57:40AM +0530, Balbir Singh wrote:
Hugh Dickins wrote:
[snip]
Without your mem_cgroup mods in mm/swap_state.c, unuse_pte makes
the right assignments (I believe). But I find that swapout (using
600M in a 512M machine
, this restructuring permits a future memory controller
patch to allocate with GFP_KERNEL in unuse_pte, where before it could not.
But it would be wrong to tuck this change away inside a memcgroup patch.)
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
This patch could go anywhere in the mm series before
-off-by: Hugh Dickins [EMAIL PROTECTED]
---
This patch should go immediately before the memory-controller patches,
or immediately before memory-controller-memory-accounting-v7.patch
mm/swapfile.c | 38 +++---
1 file changed, 7 insertions(+), 31 deletions
Why does try_to_free_mem_cgroup_pages try for order 1 pages? It's called
when mem_cgroup_charge_common would go over the limit, and that's adding
an order 0 page. I see no reason: it has to be a typo: fix it.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Insert just after memory-controller
a little later.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Insert just after
bugfix-for-memory-cgroup-controller-avoid-pagelru-page-in-mem_cgroup_isolate_pages-fix.patch
or just before memory-cgroup-enhancements
mm/memcontrol.c | 17 -
1 file changed, 4 insertions(+), 13
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 [EMAIL PROTECTED]
---
Insert just after 5/6: the tree builds okay if it goes earlier, just after
.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Insert just after memory-controller-make-charging-gfp-mask-aware.patch or
you may prefer to insert 4-6 all together before memory-cgroup-enhancements
mm/swapfile.c | 42 ++
1 file changed, 34 insertions(+), 8
On Fri, 9 Nov 2007, KAMEZAWA Hiroyuki wrote:
On Fri, 9 Nov 2007 07:14:22 + (GMT)
Hugh Dickins [EMAIL PROTECTED] 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
of code.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/shmem.c | 72 ---
1 file changed, 34 insertions(+), 38 deletions(-)
--- 2.6.24-rc3/mm/shmem.c 2007-11-07 04:21:45.0 +
On Mon, 26 Nov 2007, Andrew Morton wrote:
It is peculair to (wrongly) return -ENOMEM
+ if (shmem_reserve_inode(inode-i_sb))
+ return -ENOSPC;
and to then correct it in the caller..
Oops, I missed that completely.
Something boringly conventional such as the below,
On Wed, 5 Mar 2008, Pavel Emelyanov wrote:
Daisuke Nishimura wrote:
Todo:
- rebase new kernel, and split into some patches.
- Merge with memory subsystem (if it would be better), or
remove dependency on CONFIG_CGROUP_MEM_CONT if possible
(needs to make page_cgroup more
On Fri, 25 Jul 2008, Paul Menage wrote:
So I think we'd be complicating some of the vm paths in mainline with
a feature that isn't likely to get a lot of real use.
What do you (and others on the containers list) think? Should we ask
Andrew/Linus to hold off on this for now? My preference
On Fri, 25 Jul 2008, Paul Menage wrote:
On Fri, Jul 25, 2008 at 5:06 AM, Hugh Dickins [EMAIL PROTECTED] wrote:
(Different topic, but one day I ought to get around to saying again
how absurd I think a swap controller; whereas a mem+swap controller
makes plenty of sense. I think Rik
On Fri, 25 Jul 2008, Balbir Singh wrote:
I'll try and recreate the problem and fix it. If
memrlimit_cgroup_uncharge_as()
created the problem, it's most likely related to mm-owner not being correct
and
we are dereferencing the wrong memory.
Thanks for the bug report, I'll look further.
On Tue, 29 Jul 2008, KAMEZAWA Hiroyuki wrote:
On Fri, 25 Jul 2008 17:46:45 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
IIRC Rik expressed the same by pointing out that a cgroup at its
swap limit would then be forced to grow in mem (until it hits its
mem limit): so controlling
On Fri, 25 Jul 2008, Paul Menage wrote:
On Fri, Jul 25, 2008 at 12:46 PM, Hugh Dickins [EMAIL PROTECTED] wrote:
No, I'm trying to say something stronger than that. I'm saying,
as I've said before, that I cannot imagine why anyone would want
to control swap itself - what they want
On Fri, 25 Jul 2008, Balbir Singh wrote:
I see what your saying. When you look at Linux right now, we control swap
independent of memory, so I am not totally opposed to setting swap, instead of
swap+mem. I might not want to swap from a particular cgroup, in which case, I
set swap to 0 and
On Tue, 5 Aug 2008, Balbir Singh wrote:
Hugh Dickins wrote:
[snip]
BUG: unable to handle kernel paging request at 6b6b6b8b
IP: [7817078f] memrlimit_cgroup_uncharge_as+0x18/0x29
Pid: 22500, comm: swapoff Not tainted (2.6.26-rc8-mm1 #7)
[78161323] ? exit_mmap+0xaf/0x133
[781226b1
22 matches
Mail list logo
