Thanks for your explanation. I traced the code at __alloc_pages(). It seems that buddy allocator will wake up kswapd() when it can't fulfil the request. What is the role of kswapd here? However, I had changed kmalloc to vmalloc, and resulted in system panic. (page fault). Do you have any idea why? Many Thanks. Kuncoro Irawan On 6/23/05, Jan Hudec <bulb@xxxxxx> wrote: > On Thu, Jun 23, 2005 at 21:05:38 +0800, Kuncoro Irawan wrote: > > I have a question about internal fragmentation after allocating pages > > many times. > > As my understanding, Linux is using buddy system to avoid external > > fragmentation. > > > > Hereunder is my problem: > > > > At kernel init, pages are grouped into 10 lists of blocks that > > contains groups of 1, 2, 4, ? 512 contiguous page frames, > > respectively. > > > > Therefore, the lists has 4K, 8K,?, 4096K (page file size is 4K). > > > > Here is the lists after system initialize: (after calls mem_init() ): > > > > 1*4kB 2*8kB 0*16kB 1*32kB 2*64kB 1*128kB 0*256kB > > 1*512kB 1*1024kB 2*2048kB 0*4096kB = 5940kB > > > > After driver init and some application init, the lists become: > > > > 43*4kB 21*8kB 16*16kB 2*32kB 0*64kB 0*128kB 0*256kB > > 0*512kB 0*1024kB 0*2048kB 0*4096kB = 660kB > > > > At this point, some program _kmalloc_ 64kB and it fails because system > > does not have 64kB contiguous memory. > > > > As we can see, the available physical memory (669kB) is more than adequate. > > > > However, the memory is fragmented internally. > > > > (As I read from the book, Linux uses slab allocator to avoid internal > > fragmentation. If so, why does it still happen.) > > The slab cache is layered on top of the buddy allocator. It obviously > does not have any pages in the order 4 cache, so it goes to the buddy > allocator to get some. The buddy allocator does not have order 4 blocks > either. > > > Is there any garbage collection or memory compaction under this situation? > > You can help it a bit by carefully choosing which chunks you give away, > which will help a bit, but not solve anything. You can't shuffle things > around because pointer point to it and you have no way of fixing them. > > > Is there any solution to avoid this problem? > > Not really. > > However, there are two ways in which a chunk of memory might be > continuous. It may have continuous physical addresses, or only > continuous virtual addresses. Since you normally access memory via > virtual addresses, you can get physicaly separated pages and map them to > continuous segment of virtual memory. If you don't need to DMA to/from > that memory (DMA needs physical addresses), you can use function > vmalloc, that will allocate individual pages and map them together for > you. For DMAable memory, it is usually allocated during bootup and kept > around. > > ------------------------------------------------------------------------------- > Jan 'Bulb' Hudec <bulb@xxxxxx> > > > BodyID:8608582.2.n.logpart (stored separately) > > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
