Messages in this thread | | | From | Frank van de Pol <> | Subject | Re: Lockup 2.1.6* => kmalloc/slab ??? | Date | Sat, 8 Nov 1997 22:50:51 +0100 (MET) |
| |
Mark Hemment wrote: > > > For example, the "4096" cache uses a slab with 4 objects - that means an > allocation of 4 phyiscally contigious pages are needed to add one slab to > the cache.
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?
| |