lkml.org 
[lkml]   [2000]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Announce] BKL shifting into drivers and filesystems - beware
On Fri, 14 Jul 2000, Andrea Arcangeli wrote:
> On Fri, 14 Jul 2000, Rik van Riel wrote:
>
> >"You're not using your soundcard right now. No reason to keep
> >ISA DMA memory free now."
> >
> >Now imagine what happens when Juan wants to play some music
> >and the sound driver wants to allocate a DMA buffer...
>
> If that happens the VM have to be able to free memory from the DMA zone.
> That's the only reason memory balancing is there for.
>
> Now imagine Juan's alien-floppy driver needs 10mbyte of DMA memory to
> work. Do you suggest to keep 10mbyte of DMA memory all the time, right?

> I will never agree with that obviously bogus arguments

ROFL

Why do you always say that right *after* you write down a
bogus argument yourself? ;)

> >(also, the "classzone doesn't try to free DMA memory" contradicts
> >an earlier email by you)
>
> I may have explained me wrong, if you quote the sentence that you misread
> I'll be glad to clarify.

here it is:

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


> Classzone never and will never try to free a fixed amount of
> memory specifically from the DMA zone _unless_ somebody asks for
> __GFP_DMA memory.

So the DMA zone will be exhausted and DMA allocations will
fail when we're unlucky? That sounds like exactly the thing
zoned VM was supposed to prevent.

> >That _you_ can't see any other way doesn't mean there is
> >no better way to do these things. The solution is to have
> >a scavenge and inactive list.
>
> Scanvage/inactive list or whatever lru list is completly
> irrelevant to pass the information from the allocator to the
> memory balancing about the classzone we have to allocate from.

No.

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.

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

> And btw, in all the benchmarks I received classzone is visibly faster.

Which is not at all because of the classzone idea, but because of
some other, unrelated, optimisations.

(I can find you the relevant quote where you agreed to this, if
you insist on it)

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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.282 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site