Aristotelis Iordanidis wrote: > We've run into the same problem, working with an armnommu platform. > We tracked down the root of the high cpu load to the function > kswapd_balance_pgdat() in linux-2.4.x/mmnommu/vmscan.c. > The problem occurs only when using the non-power-of-2 memory allocator > (i.e. CONFIG_CONTIGUOUS_PAGE_ALLOC is defined). > Anyway, all this seems to be caused by the following piece of code: > > #ifndef CONFIG_CONTIGUOUS_PAGE_ALLOC /* we always want the memory now !! */ > __set_current_state(TASK_INTERRUPTIBLE); > schedule_timeout(HZ*5); > #endif > > As a workaround, we changed it as shown below, for our architecture > (e.g. CONFIG_ARCH_MINE): > > [Re-enable the time delay, but shorter, for CONTIGUOUS_PAGE_ALLOC].
That's the same as what we ended up with, for streaming HD video from disk. (The only difference is we settled on HZ/5 instead of HZ/10 in your case.) It's unfortunate that it has to be tuned for a particular application and memory size: too little delay, the and CPU is high; too much, and the reclamation rate is not sufficient for a particular rate of file reading vs free RAM, due to the "spikiness" of the reclamation process. This is where synchronous reclamation, as page_alloc.c does, would be better. It could be added to page_alloc2.c, but clearly everyone is busy doing something else :-) -- Jamie _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
