On 3/3/21 8:31 AM, Ben Widawsky wrote: >> I haven't got to the whole series yet. The real question is whether the >> first attempt to enforce the preferred mask is a general win. I would >> argue that it resembles the existing single node preferred memory policy >> because that one doesn't push heavily on the preferred node either. So >> dropping just the direct reclaim mode makes some sense to me. >> >> IIRC this is something I was recommending in an early proposal of the >> feature. > My assumption [FWIW] is that the usecases we've outlined for multi-preferred > would want more heavy pushing on the preference mask. However, maybe the uapi > could dictate how hard to try/not try. There are two things that I think are important: 1. MPOL_PREFERRED_MANY fallback away from the preferred nodes should be *temporary*, even in the face of the preferred set being full. That means that _some_ reclaim needs to be done. Kicking off kswapd is fine for this. 2. MPOL_PREFERRED_MANY behavior should resemble MPOL_PREFERRED as closely as possible. We're just going to confuse users if they set a single node in a MPOL_PREFERRED_MANY mask and get different behavior from MPOL_PREFERRED. While it would be nice, short-term, to steer MPOL_PREFERRED_MANY behavior toward how we expect it to get used first, I think it's a mistake if we do it at the cost of long-term divergence from MPOL_PREFERRED.
