On Tue 26-09-23 18:14:14, Johannes Weiner wrote:
[...]
> The fact that memory consumed by hugetlb is currently not considered
> inside memcg (host memory accounting and control) is inconsistent. It
> has been quite confusing to our service owners and complicating things
> for our containers team.
I do understand how that is confusing and inconsistent as well. Hugetlb
is bringing throughout its existence I am afraid.
As noted in other reply though I am not sure hugeltb pool can be
reasonably incorporated with a sane semantic. Neither of the regular
allocation nor the hugetlb reservation/actual use can fallback to the
pool of the other. This makes them 2 different things each hitting their
own failure cases that require a dedicated handling.
Just from top of my head these are cases I do not see easy way out from:
- hugetlb charge failure has two failure modes - pool empty
or memcg limit reached. The former is not recoverable and
should fail without any further intervention the latter might
benefit from reclaiming.
- !hugetlb memory charge failure cannot consider any hugetlb
pages - they are implicit memory.min protection so it is
impossible to manage reclaim protection without having a
knowledge of the hugetlb use.
- there is no way to control the hugetlb pool distribution by
memcg limits. How do we distinguish reservations from actual
use?
- pre-allocated pool is consuming memory without any actual
owner until it is actually used and even that has two stages
(reserved and really used). This makes it really hard to
manage memory as whole when there is a considerable amount of
hugetlb memore preallocated.
I am pretty sure there are many more interesting cases.
--
Michal Hocko
SUSE Labs
