[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44FE43E7.1030003@yahoo.com.au>
Date: Wed, 06 Sep 2006 13:43:35 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Kirill Korotaev <dev@...ru>
CC: Andrew Morton <akpm@...l.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Christoph Hellwig <hch@...radead.org>,
Pavel Emelianov <xemul@...nvz.org>,
Andrey Savochkin <saw@...ru>, devel@...nvz.org,
Rik van Riel <riel@...hat.com>, Andi Kleen <ak@...e.de>,
Oleg Nesterov <oleg@...sign.ru>,
Alexey Dobriyan <adobriyan@...l.ru>,
Matt Helsley <matthltc@...ibm.com>,
CKRM-Tech <ckrm-tech@...ts.sourceforge.net>,
Hugh Dickins <hugh@...itas.com>
Subject: Re: [PATCH 9/13] BC: locked pages (charge hooks)
Kirill Korotaev wrote:
> Introduce calls to BC core over the kernel to charge locked memory.
>
> Normaly new locked piece of memory may appear in insert_vm_struct,
> but there are places (do_mmap_pgoff, dup_mmap etc) when new vma
> is not inserted by insert_vm_struct(), but either link_vma-ed or
> merged with some other - these places call BC code explicitly.
>
> Plus sys_mlock[all] itself has to be patched to charge/uncharge
> needed amount of pages.
I still haven't heard your good reasons why such a complex scheme is
required when my really simple proposal of unconditionally charging
the page to the container it was allocated by.
That has the benefit of not being full of user explotable holes and
also not putting such a huge burden on mm/ and the wider kernel in
general.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists