>> It's not the lack of defragmentation but due bad allocation of memory.
>> Just to make an example look at the inode cache. It uses a _bad_ way to
>> alloc memory. That's the _best_ way to generate _persistent_ fragmentation
>> all over the place.
>
>Nothing is bad there, except your diagnostic, in my opinion.
In my opinion you don't understood the icache allocation code.
>Btw, I donnot want to rely on 2 PAGES allocations having to succeed most
>of the time.
It's trivial not relaying on the 8k phys consecutive memory. Simply
vmalloc if __get_free_pages fails. To know if you have to free_pages or
vfree simply check of you are towards VMALLOC_START.
Here I never had fragmentation problems but I have to say that I usually
have plenty of memory free...
>> And btw I think that for vmlloced areas would be possible to defrag them
>> at runtime, but for normal __get_free_pages memory it's not possible, it's
>> the allocation in first place that has to be smart to avoid fragmentation
>> according to me.
>
>If you lose one arm and you replace it by one of your legs, you probably
>will not be quite happy of the result. :)
>Better to do nothing than to do things that makes things worse, IMO.
??? I think you have not understood the issue. Even if a page is 8k you
may like to defrag vmalloced memory at runtime. The implementation could
be difficult and the advantage minimal but it's something that can help
with every kind of page size. I am not telling you that it has to be done
and that it will be great, it's just something that could be done (I
think, maybe I am wrong) and could be useful whith any kind of page size.
Andrea Arcangeli
-
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/