To satisfy this request, I did a quick rebase of the list-based approachThank you.
against 2.6.16-rc1-mm1 to have a comparable set of benchmarks. I will post
the patches in the morning after a re-read.
So, in terms of performance on this set of tests, both approachs performyes, this is intersiting point :)
roughly the same as the stock kernel in terms of absolute performance. In
terms of high-order allocations, zone-based appears to do better under
load. However, if you look at the zones that are used, you will see that
zone-based appears to do as well as list-based *only* because it has the
EASYRCLM zone to play with. list-based was way better at keeping the
normal zone defragmented as well as highmem which is especially obvious
when tested at rest. list-based was able to allocate 83 huge pages from
ZONE_NORMAL at rest while zone-based only managed 8.
Secondly, zone-based requires careful configuration to be successful. IfThis is because HIGHMEM is too small, right ?
booted with kernelcore=896MB for example, it only performs slightly better
than the standard kernel. If booted with kernelcore=1024MB, it tends to
perform slightly worse (more zone fallbacks I guess) and still only
manages slighly better satisfaction of high order pages.
On the flip side, zone-based code changes are easier to understand thanI agree here.
the list-based ones (at least in terms of volume of code changes). The
zone-based gives guarantees on what will happen in the future while
list-based is best-effort.
In terms of fragmentation, I still think that list-based is better overall
without configuration.
The results above also represent the best possibleOn x86, NORMAL is only 896M anyway. there is no discussion.
configuration with zone-based versus no configuration at all against
list-based. In an environment with changing workloads a constant reality,
I bet that list-based would win overall.