Telis,
I know I replied earlier saying this patch didn't help much, but that was
because I misapplied it. Correcting my original bug does fix this problem
for me! Thanks so much for the patch. I realize there is a trade-off involved
here, but our application is now very careful about how it uses memory, I don't
think we need such an aggressive use of kswapd.
Question for the developers: Why is the #ifndef conditional there at all?
Wouldn't you want to release the processor back to the scheduler when there
are no try_to_free_pages_zones?
Dave
Aristotelis Iordanidis wrote:
Hello, all.
I'm sending again a post I made about a year ago regarding a possible
solution to the high CPU load caused by page_alloc2.c:
Regards,
Telis
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):
static int kswapd_balance_pgdat(pg_data_t * pgdat)
{
int need_more_balance = 0, i;
zone_t * zone; for (i = pgdat->nr_zones-1; i
>= 0; i--) {
zone = pgdat->node_zones + i;
if (unlikely(current->need_resched))
schedule();
if (!zone->need_balance || !zone->size)
continue;
if (!try_to_free_pages_zone(zone, GFP_KSWAPD)) {
zone->need_balance = 0;
#ifdef CONFIG_ARCH_MINE
__set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ/10);
#else #ifndef CONFIG_CONTIGUOUS_PAGE_ALLOC /* we always want the memory
now !! */
__set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ*5);
#endif
#endif /* CONFIG_ARCH_MINE */
continue;
}
if (check_classzone_need_balance(zone))
need_more_balance = 1;
else
zone->need_balance = 0;
}
return need_more_balance;
}
As I understand it, the downside of this change is that it makes kswapd
less "sensitive" to handling a low memory situation.
The interval passed to schedule_timeout() above (HZ/10) showed to be the
best choice for our 80MHz ARM (larger intervals didn't make much
difference), but you might want to experiment for your platform.
I hope this helps,
Telis
_______________________________________________
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
--
David Spain
SiCortex, Inc.
Three Clock Tower Place, Suite 210
Maynard, MA USA 01754 Email: [EMAIL PROTECTED]
_______________________________________________
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
