memrlimit controller merge to mainline

Paul Menage menage at google.com
Fri Jul 25 07:06:16 PDT 2008


On Fri, Jul 25, 2008 at 5:06 AM, Hugh Dickins <hugh at veritas.com> 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 and others said the same.)

Agreed that a swap controller without a memory controller doesn't make
much sense, but a memory controller without a swap controller can make
sense on machines that don't intend to use swap.

So if they were separate controllers, we'd use the proposed cgroup
dependency features to make the swap controller depend on the memory
controller - in which case you'd only be able to mount the swap
controller on a hierarchy that also had the memory controller, and the
swap controller would be able to make use of the page ownership
information.

It's more of a modularity issue than a functionality issue, I think -
the swap controller and memory controller are tracking fundamentally
different things (space on disk versus pages in memory), and the only
dependency between them is the "memory controller" tracking the
ownership of a page and providing it to the "swap controller".

>
> By the way, here's a BUG I got from CONFIG_CGROUP_MEMRLIMIT_CTLR=y
> but no use of it, when doing swapoff a week ago.  Not investigated
> at all, I'm afraid, but at a guess it might come from memrlimit work
> placing too much faith in the mm_users count - swapoff is only one
> of several places which have to inc/dec mm_users for some reason.
>
> BUG: unable to handle kernel paging request at 6b6b6b8b

Possibly the mm->owner tracking breaks in that case, if the last user
exits while swapoff is occurring without relinquishing ownership?

That looks as though mm->owner points to a task that had been poisoned
after being freed. That could be awkward to fix :-(

Paul


More information about the Containers mailing list