Okay, that's a comprehensable reason for the failure of the allocation. But
I had expected to get some message to my console/syslog when this happens.
>
> The simple solution, is to edit mm/slab.c and change the value of;
> SLAB_BREAK_GFP_ORDER
> from 2 to 1. This will make the "4096" cache, and others, throttle back
> on the number of pages used for a slab. (In the "4096" cache, the slabs
> will have an order 1 - two physically contigious pages).
> If you are still having problems, then drop this value to 0 (but I
> wouldn't really recommend this for performance).
This sounds more like a 'quick hack' to make this problem less obvious. But
on the other hand, by increasing this SLAB_BREAK_GPF_ORDER my problem should
show up more often (and making it easier to debug :-).
>
> If you are feeling a little more adventerious, running 2.1.62 on Intel,
> and are _not_ using SMP or VM-cloned tasks (eg. not using a pthreads
> library based upon clone()), then you might want to try the patch on my
> home-page;
> http://www.nextd.demon.co.uk/patch-colour-2.1.62.gz
Not being able to use clone base threads is a show stopper for me. I don't
think I'll be able to test it within next weeks.
>
> This gives page-colouring (and a few other performance improvements)
> coupled with a weak fragmentation control. I'm calling the control weak,
> as I've out ripped all the heavy control stuff I was doing (well, was
> doing this morning). It will also speed up most CPU/memory intensive
> tasks.
Does this fragmentation control actually defragment if needed? Not being
able to allocate memory while enough free pages are present (though
fragmented) looks as a deficiency to me. What about next points? Forgive me
it these are absolute nonsens or already implented.
- In the case where enough free pages are present, but there is not a
contigious block found that is big enough: Is it not possible to rearrange
the pages (possibly using VM addressable memory to physical memory mapping)
I can imagine that 'just' moving data around really upsets the system, but
the VM hardware can take care of the address->physical address
translatlation.
Fragentation is still possible for the caches < pagesize, but then there
are 0 free pages...
If the kmalloc() allocated memory is physical memory this idea might be
false.
- If the allocation still fails try to page some memory to free a few pages.
This should only occur if we want to allocate more pages than there are
physically free. A swapping system is better than hanging system to me!
Is it possible to do something like do_try_to_free_page() from vmscan.c?
> The patch also allows the SLAB_BREAK_GFP_ORDER to be set from the boot
> line. To set it to 1, use; "slab=4,1" (don't worry too much about the
> 4, it is the minimum objects per slab the allocator _tries_ to use for a
> cache. Just keep it at '4').
So a "slab=4,0" will make the slab allocator be happy with one free page.
The allocation problem then still exists for caches > pagesize.
At this moment I have to allocate the DMA buffers for the sounddriver during
bootup. If I don't the allocation of 128kB buffers fails (not enough
contigious memory). Anyone (Mark?) knowns if solving the fragmentation will
also solve this DMA buffer allocation problem ?
> If you use the patch, could you let me know the results?
Sure, but that might take a while.
========================---------------->
#define NAME "Frank van de Pol"
#define ADDRESS "mgr. Nelislaan 10"
#define CITY "4741 AB Hoeven"
#define COUNTRY "The Netherlands"
#define EMAIL "F.K.W.van.de.Pol@inter.NL.net
Linux - Why use Windows, since there is a door?