From: Hugh Dickins <hugh@veritas.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] memcgroup: work better with tmpfs
Date: Thu, 20 Dec 2007 16:00:22 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.64.0712201553010.6414@blonde.wat.veritas.com> (raw)
In-Reply-To: <20071219093840.7d466c2b.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 19 Dec 2007, KAMEZAWA Hiroyuki wrote:
> On Tue, 18 Dec 2007 22:19:22 +0000 (GMT)
> Hugh Dickins <hugh@veritas.com> wrote:
> > 1. Why is spin_lock_irqsave rather than spin_lock needed on mz->lru_lock?
> > If it is needed, doesn't mem_cgroup_isolate_pages need to use it too?
> >
> When I wrote a patch to treat lru_lock (it was not per-zone yet.), I got a
> comment to use irqsafe version. So I wonder there is some plan which needs
> irq safe locking.
It might have come about because struct zone's lru_lock really does need
the irq disabled (because of things that happen at I/O completion time).
But I don't think struct mem_cgroup_per_zone's lru_lock needs it.
> About mem_cgroup_isolate_pages(), zone->lock is acquired with irq-disable
> before it is called. Then, it's not necesary there.
Ah, yes, I completely missed that, thank you.
>
> But as you say, it looks we can do it without irq-disable, now.
>
>
> > 2. There's mem_cgroup_charge and mem_cgroup_cache_charge (wouldn't the
> > former be better called mem_cgroup_charge_mapped? why does the latter
> > test MEM_CGROUP_TYPE_ALL instead of MEM_CGROUP_TYPE_CACHED? I still don't
> > understand your enums there). But there's only mem_cgroup_uncharge.
> > So when, for example, an add_to_page_cache fails, the uncharge may not
> > balance the charge?
> >
> Ah...it seems bug. We should add type handling in uncharge.
> Then, changing control_type after start using mem_cgroup seems dangerous.
> (Default is ALL now.)
>
> Maybe following will be fix.
>
> - allow changing contorl_type only when there is no task.
> - run force_empty when control_type is changed. and drop all charges.
>
> This will change current behavior but I think it's reasonable.
> How do you think ?
Perhaps... my grasp on this is much too weak to be sure:
I'm pretty sceptical about changing control_type altogether.
Let me reply to Balbir, who still sees no issue there.
Hugh
next prev parent reply other threads:[~2007-12-20 16:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 22:19 Hugh Dickins
2007-12-18 22:20 ` [PATCH 1/2] memcgroup: tidy up mem_cgroup_charge_common Hugh Dickins
2007-12-18 22:22 ` [PATCH 2/2] memcgroup: fix hang with shmem/tmpfs Hugh Dickins
2007-12-19 0:38 ` [PATCH 0/2] memcgroup: work better with tmpfs KAMEZAWA Hiroyuki
2007-12-20 16:00 ` Hugh Dickins [this message]
2007-12-19 5:53 ` Balbir Singh
2007-12-20 16:36 ` Hugh Dickins
2007-12-20 18:13 ` 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=Pine.LNX.4.64.0712201553010.6414@blonde.wat.veritas.com \
--to=hugh@veritas.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®