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

Martin J. Bligh
2005-11-02T14:57:01Z

> reliable hot-remove of generic kernel RAM is plain impossible even in a
> fully virtualized solution. It's impossible even with maximum hardware
> help. We simply dont have the means to fix up live kernel pointers still
> linked into the removed region, under the C programming model.
>
> the hurdles towards a reliable solution are so incredibly high, that
> other solutions _have_ to be considered: restrict the type of RAM that
> can be removed, and put it into a separate zone. That solves things
> easily: no kernel pointers will be allowed in those zones. It becomes
> similar to highmem: various kernel caches can opt-in to be included in
> that type of RAM, and the complexity (and maintainance impact) of the
> approach can thus be nicely scaled.

Forget about freeing up arbitrary regions of RAM. I don't think anyone has
strong enough drugs to seriously believe that works in the generic case.
What we need is to free a small region of RAM, that's contiguous. Larger
than one page, likely a few MB. Exactly WHICH region is pretty irrelevant,
since mostly we just want one contiguous chunk to use.

Hypervisors do not remap at page-level granularity - that seems to be
the source of some of the confusion here.