On 09.02.21 14:25, Michal Hocko wrote:
On Tue 09-02-21 11:23:35, David Hildenbrand wrote:
> I am constantly trying to fight for making more stuff MOVABLE instead of
> going into the other direction (e.g., because it's easier to implement,
> which feels like the wrong direction).
> Maybe I am the only person that really cares about ZONE_MOVABLE these days
> :) I can't stop such new stuff from popping up, so at least I want it to be
MOVABLE zone is certainly an important thing to keep working. And there
is still quite a lot of work on the way. But as I've said this is more
of a outlier than a norm. On the other hand movable zone is kinda hard
requirement for a lot of application and it is to be expected that
many features will be less than 100% compatible. Some usecases even
impossible. That's why I am arguing that we should have a central
document where the movable zone is documented with all the potential
problems we have encountered over time and explicitly state which
features are fully/partially incompatible.
I'll send a mail during the next weeks to gather current restrictions to
document them (and include my brain dump). We might see more excessive
use of ZONE_MOVABLE in the future and as history told us, of CMA as
well. We really should start documenting/caring.
@Mike, it would be sufficient for me if one of your patches at least
mention the situation in the description like
"Please note that secretmem currently behaves much more like long-term
GUP instead of mlocked memory; secretmem is unmovable memory directly
consumed/controlled by user space. secretmem cannot be placed onto
As long as there is no excessive use of secretmem (e.g., maximum of 16
MiB for selected processes) in combination with ZONE_MOVABLE/CMA, this
is barely a real issue. However, it is something to keep in mind when a
significant amount of system RAM might be used for secretmem. In the
future, we might support migration of secretmem and make it look much
more like mlocked memory instead."
Just a suggestion.
David / dhildenb