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

[Martin J. Bligh]

>> I agree enough on concept that I think we can go implement at least a
>> demonstration of how easy it is to perform.
>> 
>> There are a couple of implementation details that will require some
>> changes to the current zone model, however.  Perhaps you have some
>> suggestions on those.
>> 
>> In which zone do we place hot-added RAM?  I don't think answer can
>> simply be the HOTPLUGGABLE zone.  If you start with sufficiently small
>> of a machine, you'll degrade into the same horrible HIGHMEM behavior
>> that a 64GB ia32 machine has today, despite your architecture.  Think of
>> a machine that starts out with a size of 256MB and grows to 1TB.
>> 
> 
> What can we do reasonably sanely? I think we can drive about 16GB of
> highmem per 1GB of normal fairly well. So on your 1TB system, you
> should be able to unplug 960GB RAM.

I think you need to talk to some more users trying to run 16GB ia32
systems. Feel the pain.
 
> Lower the ratio to taste if you happen to be doing something
> particularly zone normal intensive - remember in that case the frag
> patches won't buy you anything more because a zone normal intensive
> workload is going to cause unreclaimable regions by definition.
> 
>> So, if you have to add to NORMAL/DMA on the fly, how do you handle a
>> case where the new NORMAL/DMA ram is physically above
>> HIGHMEM/HOTPLUGGABLE?  Is there any other course than to make a zone
>> required to be able to span other zones, and be noncontiguous?  Would
>> that represent too much of a change to the current model?
>> 
> 
> Perhaps. Perhaps it wouldn't be required to get a solution that is
> "good enough" though.
> 
> But if you can reclaim your ZONE_RECLAIMABLE, then you could reclaim
> it all and expand your normal zones into it, bottom up.

Can we quit coming up with specialist hacks for hotplug, and try to solve
the generic problem please? hotplug is NOT the only issue here. Fragmentation
in general is.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/