> 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. > >>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
