lkml.org 
[lkml]   [1997]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: useful LKM?
From
Date
> 
> Andi Kleen <ak@muc.de> wrote:
> > Often is doesn't matter anyways, because the kmalloc() Linux uses always
> > rounds the block size to the next power of 2. Only when this additional
> > field causes the structure size to go into the next 'order' (e.g. from 32
> > to 64 bytes) it'll cost you memory. The kmalloc emulation on top of slab
> > in 2.1 is power-of-2 based too, if you use slap directly the effect is
> > still there (because slab aligns the objects in the page for the cache
> > colouring), but much less. Most structures in Linux are still managed
> > by kmalloc() though..
>
> Er... I'm not sure I understand this. It sounds as if it doesn't
> matter what offsets are used for the various fields of a structure.
> But if that's the case, why should it matter whether the kernel and
> the module agree on the structure definition at all?
Of course it matters. If not they can't communicate.

>
> Is there some kind of interface layer in there that looks at the
> mechanical definition of the deviant structures across the two sides of
> the interface, then adjusts what's in memory as control passes across
> the barrier???
No. This isn't Windows NT ...

>
> Or is this just a case where something is advertised for export, but
> not really used??
Yes. My point was just that it often doesn't matter if a field is defined or
not, because the memory is wasted anyways. One has to be careful though,
the choice between wasted or not is often different between 32bit and 64bit
machines, when pointers are used.

-Andi

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.026 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site