Re: [patch] improve streaming I/O [bug in shrink_mmap()]

From: Rik van Riel (riel@conectiva.com.br)
Date: Wed Jun 14 2000 - 08:44:18 EST


On Wed, 14 Jun 2000, Andrea Arcangeli wrote:
> 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
> >break.
>
> 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.

So if the ZONE_DMA is filled by mlock()ed memory, classzone
will *not* try to balance it? Will classzone *only* try to
balance the big classzone containing zone_dma, and not the
dma zone itself? (since the dma zone doesn't contain any
other zone, doesn't it need to be balanced?)

> 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.

A few mails back you wrote that the classzone patch would
do just about the same if a _classzone_ fills up. (except
that the different shrink_mmap() causes it to go to sleep
before being woken up again at the next allocation)

regards,

Rik

--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/

- 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