On Tue, 13 Jun 2000, Rik van Riel wrote:
>But when you switch around the order of allocation in your
>hypothetical example, allocating the cache first, from the
>ZONE_NORMAL and then proceeding to mlock the rest of the
>normal zone and the dma zone, then classzone will still
It doesn't break anything. You'll simply will not able to allocate memory
with GFP_DMA anymore (that was happening seldom also in 2.2.x). If all the
DMA zone is mlocked not being able to return GFP_DMA memory is normal.
If all the ZONE_NORMAL is mlocked but the ZONE_DMA is filled by cache
having kswapd that loops forever wasting CPU in the ZONE_NORMAL is
a broken behaviour IMHO.
>Conveniently snipping out the part of my post where I proved
>your example wrong is not what I'd call constructive dialog.
You repeated the same thing many times and so I left only the part
underlined below in the reply.
On Wed, 14 Jun 2000, Andrea Arcangeli wrote:
>Date: Wed, 14 Jun 2000 04:10:08 +0200 (CEST)
>From: Andrea Arcangeli <firstname.lastname@example.org>
>To: Rik van Riel <email@example.com>
>Cc: Juan J. Quintela <firstname.lastname@example.org>, Stephen C. Tweedie <email@example.com>,
> Zlatko Calusic <firstname.lastname@example.org>, email@example.com,
> Linux MM List <firstname.lastname@example.org>,
> Linux Kernel List <email@example.com>,
> Linus Torvalds <firstname.lastname@example.org>
>Subject: Re: [patch] improve streaming I/O [bug in shrink_mmap()]
>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
>>> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:11 EST