On Fri 17-07-20 12:37:57, David Rientjes wrote: [...] > On a 4.3 kernel, for example, memory.current for the heap segment is now > (64MB / 2MB) * 4KB = 128KB because we have synchronous splitting and > uncharging of the underlying hugepage. On a 4.15 kernel, for example, > memory.current is still 64MB because the underlying hugepages are still > charged to the memcg due to deferred split queues. Deferred THP split should be a kernel internal implementation optimization and a detail that userspace shouldn't really be worrying about. If there are user visible effects that are standing in the way then we should reconsider how much is the optimization worth. I do not really remember any actual numbers that would strongly justify its existence while I do remember several problems that this has introduced. So I am really wondering whether exporting subtle metrics to the userspace which can lead to confusion is the right approach to the problem you have at hands. Also could you be more specific about the numbers we are talking here? E.g. what is the overal percentage of the "mis-accounted" split THPs wrt. to the high/max limit? Is the userspace relying on very precise numbers? -- Michal Hocko SUSE Labs
