There may be some entertainment there all right. I didn't see any obvious
way of avoiding collisions with those patches but for what it's worth,
ZONE_MOVABLE could also be made optional.
In this patchset, I made no assumptions about the number of zones other
than the value of MAX_NR_ZONES. There should be no critical collisions but
I'll look through this patch list and see what I can spot.
This patch looks ok and looks like it stands on it's own.
ok, no collisions here but obviously this patch does not stand on it's
own.
There are collisions here with the __ZONE_COUNT stuff but it's not
difficult to work around.
There is no cross-over here with the ZONE_MOVABLE patches. They are
messing around with slab
No collision here
No collisions here either. I see that there were discussions about Power
potentially doing something similar.
No collisions
Fun, but no collisions.
To my suprise, I only spotted one major conflict point with
optional-zone_dma-in-the-vm.patch and that should be easy enough to
resolve. What I could do is break up one of my patches into
most-of-the-patch and the-part-that-may-conflict-with-optional-dma-zone .
The smaller part would then change depending on whether the optional DMA
zone work is present. Would that be any help?
I haven't thought about it much so I probably am missing something. The
major difference I see is when only one zone is present. In that case, a
number of loops presumably get optimised away and the behavior is very
different (presumably better although you point out no figures exist to
prove it). Where there are two or more zones, the code paths should be
similar whether there are 2, 3 or 4 zones present.
As the common platforms will always have more than one zone, it'll be
heavily tested and I'm guessing that distros are always going to have to
ship kernels with ZONE_DMA for the devices that require it. The only
platform I see that may have problems at the moment is IA64 which looks
like the only platform that can have one and only one zone. I am guessing
that Christoph will catch problems here fairly quickly although a
non-optional ZONE_MOVABLE would throw a spanner into the works somewhat.
hmm. Assuming the aim is to have a situation where all zone-related loops
are optimised away at compile-time, it's hard to see an alternative that
works. Any dynamic way of creating zone at boot time will not have the
compile-time optimizations and any API that is page-range aware will
eventually hit the problems zones were made to solve (i.e. unmovable pages
locked in the lower address ranges).
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
