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?
Now imagine that Juans never play mp3 today, he will be happy to waste
10mbytes of memory and CPU resources for no one good reason, right?
I will never agree with that obviously bogus arguments and my tree will
never waste memory and CPU in such a silly way.
>(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.
Just to make things clear:
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.
classzone can definitely happen to shrink from the DMA zone because the
DMA zone is part of the NORMAL and HIGHMEM zones. But it may free only 1
page from the DMA zone and the rest from other zones. (if the allocation
never use __GFP_DMA)
>> What I mean is that if shrink_mmap doesn't get a zone_t pointer
>> as parameter, the VM will always end doing something wrong.
>> There's no way to fix that except reinserting the parameter that
>> gives the information about the allocation as I did in
>> classzone.
>
>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. Your argument is flawed and you
really don't see the problem (or you don't want to see it).
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.
And btw, in all the benchmarks I received classzone is visibly faster.
The only negative report I received about classzone was from hpa and I
still think it was the old sync_page_buffers plus the free_before_allocate
that I inserted in ac22class that made the system not repsonsive under
background I/O to disk (I addressed both issues in a new better way in
VM-global-patch-3; so far I ported the BH_Wait_IO thing to
2.4.0-test4-pre6 plus all the other VM changes and it apparently works
well here too, I'm running it while writing this email ;) I'll port the
allocator race fixes to my VM tree soon too.
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:21 EST