Skip to contentSkip to conversation

A question about memory fragmentation

DISCUSSION Abel Mu�oz Alcaraz 3 participants 3 messages Nov 7, 2000

lore
Share & tools
lore
#0 lore raw

Hi everybody,

Thank you for your help!
I am going to tell you more information.

my question is about memory fragmentation when I allocate and free a lot of
small memory pieces in a kernel module.
Can it do a memory fragmentation problem?
Can I solve it using 'linux/list.h' API?

I think that is better to allocate a big piece of memory and get the nodes
from this buffer with my own memory management functions; Is this correct?.

Thanks.

Abel Muñoz Alcaraz.
Media Security Software Developer.
mailto:[email protected]
Trymedia Systems

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Quoted 5 lines · Abel Muñoz Alcaraz

my question is about memory fragmentation when I allocate and free a lot of
small memory pieces in a kernel module.
Can it do a memory fragmentation problem?
Can I solve it using 'linux/list.h' API?

Fragmentation is not really an issue there. Linux maintains a pool of pages of different sizes, and you will be allocated a page with the next size superior to what you ask for. Sizes are all powers of two, so the worst case would be that you ask 2^n+1 bytes and get a 2^(n+1) size page. When you free such a page, it is merged if needed with a coalescent page and put back in the "upper size" pool (not sure about this, though). So, no fragmentation is to be feared.

As to whether you use list.h or not, it really doesn't have any influence, except that the list.h implementation is the preferred and standard way to make doubly linked lists under Linux.

So, no, there's no need to allocate one big pool and manage it yourself. Also remember that you can only kmalloc() up to 128k - if you want to allocate bigger amounts of memory, use vmalloc().

Another solution: create your own slab cache for your objects.

Signature · 9 lines
Francis Galiegue, [email protected]
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race"  -- R. Cook

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#2 lore raw
In reply to Abel Mu�oz Alcaraz
Quoted 4 lines

I think that is better to allocate a big piece of memory and get the n=
odes
from this buffer with my own memory management functions; Is this corre= ct?.

See the SLAB interface. It'll do that for you. Kmalloc uses SLAB so will do similarly sane things

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/