On Tue, 13 Jun 2000, Rik van Riel wrote:
>On Wed, 14 Jun 2000, Andrea Arcangeli wrote:
>
>> >and we can support all corner cases of usage well without it. In
>> >fact, as I demonstrated above, even your own contorted example will
>> >hang classzone if I only switch the order in which the allocations
>> >happen...
>>
>> It won't hang, but kswapd will eat CPU and that's right in your case. The
>> difference that you can't see is that in the second scenario where the
>> classzone would spend CPU in kswapd the CPU is spent for a purpose that
>> have a sense. In the first scenario where classzone wouldn't any spend
>> CPU, the CPU in kswapd would infact be _wasted_.
>
>Now explain to me *why* this happens. I'm pretty sure this happens
>because of the 'dispose = &old' in shrink_mmap and not because of
>anything even remotely classzone related...
You waste CPU in kswapd in the first scenario simply because you are not
looking backwards at the ZONE_DMA state at the time you have to choose if
you did some progress on the ZONE_NORMAL zone.
You did progress in the ZONE_DMA because it was all cache so then kswapd
should understand even if nothing is been freed from the ZONE_NORMAL, we
just have enough marging for the next GFP_KERNEL allocation too (not only
for the GFP_DMA allocations), thus it should stop looping. There's just
enough free memory for both zones.
The problem isn't related to shrink_mmap, but only to the zone design
(proper classzone part).
>I'm trying to improve the Linux kernel here, I'd appreciate it if
>you were honest with me.
Are you saying I'm not been honest with you? JFYI: I don't enjoy to get
insulted by you (and it's not the first time). I will ignore also your
above comment but please don't insult me anymore in the future! Thanks.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:30 EST