On Wed, 14 Jun 2000, Rik van Riel wrote:
>So if the ZONE_DMA is filled by mlock()ed memory, classzone
>will *not* try to balance it? Will classzone *only* try to
It will try but it won't succeed.
>balance the big classzone containing zone_dma, and not the
>dma zone itself? (since the dma zone doesn't contain any
No, I definitely try to balance the DMA zone itself. But in such case (all
DMA zone mlocked) kswapd will just spend CPU trying to balance the zone
but it _can't_ succeed because mlocked just means we can't even attempt to
move such memory elsewhere in the physical space or we'll break userspace
critical latency needs.
>other zone, doesn't it need to be balanced?)
Yes, I of course agree, it needs to be balanced and classzone will try to
balance it.
>A few mails back you wrote that the classzone patch would
>do just about the same if a _classzone_ fills up. (except
What you mean with "just about the same"? You mean spending CPU in kswapd
trying to release some memory? If so yes. When a classzone fills up kswapd
will spend cpu trying to free some memory so that the next
GFP_DMA/GFP_KERNEL/GFP_HIGHUSER allocation (depending on the classzone
that is low on memory) will succeed.
>that the different shrink_mmap() causes it to go to sleep
>before being woken up again at the next allocation)
In classzone shrink_mmap doesn't control in any way how kswapd will react
to low memory conditions. Only the level of memory of the classzones are
controlling kswapd. If classzone is low on memory kswapd will keep to try
to shrink it.
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:31 EST