If it's configure as ZONE_NORMAL, you need to pray for offlining memory.
AFAIK, IBM's ppc? has 16MB section size. So, some of sections can be
offlined
even if they are configured as ZONE_NORMAL. For them, placement of offlined
memory is not important because it's virtualized by LPAR, they don't try
to remove DIMM, they just want to increase/decrease amount of memory.
It's an another approach.
But here, we(fujitsu) tries to remove a system board/DIMM.
So, configuring the whole memory of a node as ZONE_MOVABLE and tries to
guarantee
DIMM as removable.
quoted
quoted
IMHO, I don't think shrink_slab() can kill all objects in a node even
if they are some caches. We need more study for doing that.
Indeed, shrink_slab can only kill cached objects. They, however, are
usually a very big part of kernel memory. I wonder though if in case of
failure, it is worth it to try at least one shrink pass before you
give up.
Yeah, now, his (our) approach is never allowing kernel memory on a node
to be
hot-removed by ZONE_MOVABLE. So, shrink_slab()'s effect will not be seen.
Ok, that clarifies it to me.
If other brave guys tries to use ZONE_NORMAL for hot-pluggable DIMM, I see,
it's worth triying.
I was under the impression that this was being done in here.
How about checking the target memsection is in NORMAL or in MOVABLE at
hot-removing ? If NORMAL, shrink_slab() will be worth to be called.
Yes, this is what I meant. I think there is value investigating this,
since for a lot of workloads, a lot of the kernel memory will consist of
shrinkable cached memory. It would provide you with the same level of
guarantees (zero), but can improve the success rate (this is, of
course, a guess)
BTW, shrink_slab() is now node/zone aware ? If not, fixing that first will
be better direction I guess.
It is not upstream, but there are patches for this that I am already
using in my private tree.