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

[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