All of lore.kernel.org
 help / color / mirror / Atom feed
* module allocation
@ 2006-04-28 13:04 moreau francis
  2006-04-28 20:03 ` Ralf Baechle
  0 siblings, 1 reply; 4+ messages in thread
From: moreau francis @ 2006-04-28 13:04 UTC (permalink / raw)
  To: linux-mips

Hi

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...

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

Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: module allocation
  2006-04-28 13:04 module allocation moreau francis
@ 2006-04-28 20:03 ` Ralf Baechle
  2006-05-02  7:19   ` Re : " moreau francis
  0 siblings, 1 reply; 4+ messages in thread
From: Ralf Baechle @ 2006-04-28 20:03 UTC (permalink / raw)
  To: moreau francis; +Cc: linux-mips

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re : module allocation
  2006-04-28 20:03 ` Ralf Baechle
@ 2006-05-02  7:19   ` moreau francis
  2006-05-02  9:36     ` Ralf Baechle
  0 siblings, 1 reply; 4+ messages in thread
From: moreau francis @ 2006-05-02  7:19 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: linux-mips

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

BTW, I don't see why -mlong-calls wouldn't be needed for GFP module
allocation. Can you explain ?

Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Re : module allocation
  2006-05-02  7:19   ` Re : " moreau francis
@ 2006-05-02  9:36     ` Ralf Baechle
  0 siblings, 0 replies; 4+ messages in thread
From: Ralf Baechle @ 2006-05-02  9:36 UTC (permalink / raw)
  To: moreau francis; +Cc: linux-mips

On Tue, May 02, 2006 at 07:19:49AM +0000, moreau francis wrote:

> > There is another reason against putting modules into mapped space and
> > that's the need for -mlong-calls which generates larger, less efficient
> > code.
> 
> BTW, I don't see why -mlong-calls wouldn't be needed for GFP module
> allocation. Can you explain ?

It assumes a low-memory system where the entire RAM resides within the
range of a J/JAL instructions.

  Ralf

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-05-02  9:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-28 13:04 module allocation moreau francis
2006-04-28 20:03 ` Ralf Baechle
2006-05-02  7:19   ` Re : " moreau francis
2006-05-02  9:36     ` Ralf Baechle

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.