Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

Joel Schopp
2005-11-01T20:59:13Z

>> The patches have gone through a large number of revisions, have been
>> heavily tested and reviewed by a few people. The memory footprint of this
>> approach is smaller than introducing new zones. If the cache footprint,
>> increased branches and instructions were a problem, I would expect
>> them to
>> show up in the aim9 benchmark or the benchmark that ran ghostscript
>> multiple times on a large file.
>>
>
> I appreciate that a lot of work has gone into them. You must appreciate
> that they add a reasonable amount of complexity and a non-zero perormance
> cost to the page allocator.

The patches do ad a reasonable amount of complexity to the page allocator. In
my opinion that is the only downside of these patches, even though it is a big
one. What we need to decide as a community is if there is a less complex way to
do this, and if there isn't a less complex way then is the benefit worth the
increased complexity.

As to the non-zero performance cost, I think hard numbers should carry more
weight than they have been given in this area. Mel has posted hard numbers that
say the patches are a wash with respect to performance. I don't see any
evidence to contradict those results.

>> The will need high order allocations if we want to provide HugeTLB pages
>> to userspace on-demand rather than reserving at boot-time. This is a
>> future problem, but it's one that is not worth tackling until the
>> fragmentation problem is fixed first.
>>
>
> Sure. In what form, we haven't agreed. I vote zones! :)

I'd like to hear more details of how zones would be less complex while still
solving the problem. I just don't get it.