On Fri, Jul 25, 2008 at 5:06 AM, Hugh Dickins <hugh@xxxxxxxxxxx> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers