On Fri, 14 Jul 2000, Rik van Riel wrote:
>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
What does it mean ROFL?
>Why do you always say that right *after* you write down a
>bogus argument yourself? ;)
It depends from the point of view. In my opinion your argument is
bogus ;)
>> >(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.
What I meant is "it will try if Juan insmod the ISA sound driver (or open
the sound device depending on the module implmenetation)".
>>
>> >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
Again I definitely try to balance the DMA zone itself "only _as_soon_as_
Juan asks for a __GFP_DMA allocation".
If Juan never asks for a __GFP_DMA allocation classzone will _never_ try
to balance the ZONE_DMA.
That's how it works now and how it _always_ worked in the past. If I
explained myself wrong I apologise. If you go back to check the old code
you'll get the confirm (nothing is changed in such area).
I think to recall the discussion was more about _what_ happens if we try
to balance the ZONE_DMA and _not_ _when_ we try to do that. So I probably
assuemd we was _just_ in the case Juan asked for __GFP_DMA memory.
>------------> 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.
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 in bigmem we also have 3 zones since
people is able to use 2.2.x with 4giga of RAM).
The only new thing is that now the zone design is generalized, more object
oriented, while previously it was just dedicated for 1 2 3 zones. Now you
can have 10 zones and you don't have to copy stuff as we had to do to add
the bigmem zone in 2.2.x.
And of course since the kernel memory is not relocatable or freeable you
will _never_ have the garantee that you can allocate DMA memory, whatever
you do. To have that garantee you should disallow any kernel allocation to
happen in DMA memory and that would penalize the memory usage a lot.
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) won't help at
all to make the allocation more reliable because you are not allowed to
return such additional 1mbyte of RAM because such additional 1mbyte of ram
is under the low watermark so you'll have to start memory balancing
anyway. And if memory balancing fails as best you won't be able to return
more than the low watermark anwyay.
>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
unless Juan asks for __GFP_DMA memory _but_ without knowing _when_ and
_if_ Juan asks/asked for __GFP_DMA memory. 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? Go ahead, but I'm sorry if I won't throw away my
obviously right approch until I can replace it with something else to
avoid my memory and CPU esources to be wasted in the menatime.
>> 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).
>> 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)
Yes, the big difference during swap is because of the swap_cache that
isn't polluting the VM anymore thanks to the split of the lru to lru_cache
and lru_swap_cache that I could do after being able to separate the active
(mapped) to the inactive (unmapped) pages. The other difference during
high cache re-cycling is because I don't waste time on active (mapped)
pages anymore.
But that really doesn't mean the very classzone part isn't improving a lot
the performance too for all the corner cases where the current 2.4.x VM is
doing senseless actions instead. I see classzone more as a correctness
issue and of course avoiding doing not helpful work also means to be
faster and better spend the hardware resources we have.
As said I will be glad to extract the very classzone part from my VM tree
if somebody is interested.
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 : Sat Jul 15 2000 - 21:00:20 EST