Re : module allocation

Re : module allocation

[moreau francis]

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

Ok, to sum up things:

Pros:
  - allocation granularity is a page size  where as GFP allocations is a power
    of two...
  - better chance for the module to get loaded into fragmented memory.

Cons:
  - it consumes TLB entries, (usually one ?)
  - it needs to generate the module with "-mlong-calls" switch which generates
    larger and less efficient code.
  - there will be a refill exception overhead each time the module code will be
    executed and it's not mapped through TLB.

maybe that would make sense to do some benchmarks ?

Thanks

Re: Re : module allocation

[Ralf Baechle]

On Sat, Apr 29, 2006 at 11:41:01AM +0200, moreau francis wrote:

> maybe that would make sense to do some benchmarks ?

It would be interesting to actually have some numbers, yes.  I expect the
impact to be significantly less than of the PIC code used for userspace.

  Ralf

Re: module allocation

[Ralf Baechle]

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

Re : module allocation

[moreau francis]

> 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

Re: Re : module allocation

[Ralf Baechle]

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