Hello.
On Wed, Nov 27, 2019 at 01:44:46PM +0100, Giuseppe Scrivano <gscrivan@xxxxxxxxxx> wrote:
> - hugetlb.<hugepagesize>.current
> - hugetlb.<hugepagesize>.max
> - hugetlb.<hugepagesize>.events
Just out of curiosity (perhaps addressed to Mike), does this naming
account for the potential future split between reservations and
allocations charges?
> --- a/mm/hugetlb_cgroup.c
> +++ b/mm/hugetlb_cgroup.c
> [...]
> - if (!page_counter_try_charge(&h_cg->hugepage[idx], nr_pages, &counter))
> + if (!page_counter_try_charge(&h_cg->hugepage[idx], nr_pages,
> + &counter)) {
> ret = -ENOMEM;
> + cgroup_file_notify(&h_cg->events_file);
> + }
Two notes to this:
1) Is that on purpose that the events_file (and hence notifications) are
shared across various huge page sizes?
2) Note that page_counter_try_charge checks hierarchically all counters
(not just the current h_cg's) and the limit may also be hit in an
ancestor (the third argument). I.e. the notification should be triggered
in the cgroup that actually crossed the limit.
Furthermore, the hierarchical and local events. I suggest looking at
memcg_memory_event for comparison.
If I take one step back. Is there a consumer for these events? I can see
the reasoning is the analogy with memcg's limits and events [1] but
wouldn't be a mere .stats file enough?
Michal
Attachment:
signature.asc
Description: Digital signature
