Re: [Announce] BKL shifting into drivers and filesystems - beware

From: Rik van Riel (riel@conectiva.com.br)
Date: Fri Jul 14 2000 - 16:15:34 EST


On Fri, 14 Jul 2000, Andrea Arcangeli wrote:
> On Fri, 14 Jul 2000, Rik van Riel wrote:
> >On Fri, 14 Jul 2000, Andrea Arcangeli wrote:

> Again I definitely try to balance the DMA zone itself "only
> _as_soon_as_ Juan asks for a __GFP_DMA allocation".

Which is too late. That will lead to the typical
"DMA buffer allocation failed" error message and
the user will come to us complaining that the sound
card no longer works after applying the VM patch.

> If Juan never asks for a __GFP_DMA allocation classzone will
> _never_ try to balance the ZONE_DMA.

Which is wrong.

> Zoned VM is not a new thing. We have it in 2.0.x since we was
> able to use IDE DMA. We have it in 2.2.x

And the failed DMA buffer allocations are exactly the reason why
we introduced a VM where *all* zones have some free pages...

> Anyway also ignoring the above point, keeping say 1 mbyte of RAM
> free in the ZONE_DMA despite nobody is using it (as you're
> doing)

Stephen and me have worked out a proposal where we no longer
need a free list for stuff like this. That is, we'll have no
need to keep around a free list just in case a situation like
this happens.

> >If we age the pages from *all* zones the same, we can easily
> >see which zone has the largest percentage/number/.. of old
> >pages.
> >
> >In that case the allocator can have a pretty good idea where
> >to do its next allocation. This fixes balancing between zones
> >without us having to throw away data early.
>
> I'd like to see this code that should avoid the DMA zone to be
> balanced

All zones should be balanced up to a certain amount and on
top of that the _global_ amount of memory we have should be
balanced a bit more so we can do inter-zone balancing.

> Send me a patch so I can see how it works. My approch is trivial
> and obviously right and lightweight. You want to make complex?

s/obviously right//

Failing to allocate a DMA buffer because we kept around our
magic number of free pages somewhere else just isn't right.
(especially not since we are keeping around those free pages)

> >> You just say that changing the memory balancing algorithm can
> >> fix it. It _can't_ because you don't have an information that
> >> only the allocator can give it to you. Nobody else know that
> >> information. It's not changing the algorithm that you'll get
> >> _that_ information. No-way.
> >
> >Ermm, and what information would that be?
>
> As just said it's a thing called "zone_t *" that alloc_pages
> (the allocator) was used to pass to try_to_free_pages (the
> memory balancing code).

Which is very very wrong.

In most of the allocations the allocator won't care at all
in which zone the page is allocated. In that case we want to
replace the least used page from memory, regardless of in
which zone that page resides.

regards,

Rik

--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

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 : Sat Jul 15 2000 - 21:00:20 EST