linux-mips
[Top] [All Lists]

Re: module allocation

To: moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: module allocation
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 28 Apr 2006 21:03:07 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <20060428130417.71285.qmail@web25813.mail.ukl.yahoo.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060428130417.71285.qmail@web25813.mail.ukl.yahoo.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.2.1i
On Fri, Apr 28, 2006 at 01:04:17PM +0000, moreau francis wrote:

> Maybe a silly question...why do we use mapped memory (allocated by
> vmalloc) for inserting a module into the kernel ?
> 
> I can see only drawbacks:
> 
>   - It consumes TLB entries,
> 
>   - When accessing to the module's code, we use TLB entries which can
>     be bad for interrupt latencies. For instance: if the module has an
>     interrupt handler and the module's code in still not mapped in the
>     TLB, we got a page fault...

Not quite.  There will be a TLB reload exception but that it's.  These
TLB entries are all marked global, dirty and valid so the overhead is
as big as in the best case for user pages.

>   - Modules are usually loaded at startup, at this time the memory
>     should not be fragmented.

Usually but not always and we need to guarantee that things are working
under all circumstances.

There is another reason against putting modules into mapped space and
that's the need for -mlong-calls which generates larger, less efficient
code.

One disadvantage of using GFP allocations would be that they're rounding up
the memory allocations to the next power of two, so a 40k module for
example would actually allocate 64k ...

  Ralf

<Prev in Thread] Current Thread [Next in Thread>