linux-kernel - Re: [PATCH] fs, mm: account filp and names caches to kmemcg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Oct 2017 11:10:42 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Greg Thelen <gthelen@...gle.com>
Cc:     Shakeel Butt <shakeelb@...gle.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux MM <linux-mm@...ck.org>, linux-fsdevel@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Johannes Weiner <hannes@...xchg.org>
Subject: Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Mon 09-10-17 20:17:54, Michal Hocko wrote:
> the primary concern for this patch was whether we really need/want to
> charge short therm objects which do not outlive a single syscall.

Let me expand on this some more. What is the benefit of kmem accounting
of such an object? It cannot stop any runaway as a syscall lifetime
allocations are bound to number of processes which we kind of contain by
other means. If we do account then we put a memory pressure due to
something that cannot be reclaimed by no means. Even the memcg OOM
killer would simply kick a single path while there might be others
to consume the same type of memory.

So what is the actual point in accounting these? Does it help to contain
any workload better? What kind of workload?

Or am I completely wrong and name objects can outlive a syscall
considerably?

-- 
Michal Hocko
SUSE Labs