From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751801AbdJ2CjJ (ORCPT <rfc822;w@1wt.eu>);
        Sat, 28 Oct 2017 22:39:09 -0400
Received: from bombadil.infradead.org ([65.50.211.133]:35910 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751654AbdJ2CjH (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 28 Oct 2017 22:39:07 -0400
Date: Sat, 28 Oct 2017 19:39:00 -0700
From: Matthew Wilcox <willy@infradead.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Yang Shi <yang.s@alibaba-inc.com>, Jan Kara <jack@suse.cz>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-mm@kvack.org,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg
Message-ID: <20171029023900.GA11276@bombadil.infradead.org>
References: <1509128538-50162-1-git-send-email-yang.s@alibaba-inc.com>
 <CAOQ4uxiFA8FDoFU8cNGYoJeiuTFOE9-fgsG4xtnM=9zfAJ+k2g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOQ4uxiFA8FDoFU8cNGYoJeiuTFOE9-fgsG4xtnM=9zfAJ+k2g@mail.gmail.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Oct 28, 2017 at 05:19:36PM +0300, Amir Goldstein wrote:
> <suggest rephrase>
> Due to the current design of kmemcg, the memcg of the process who does the
> allocation gets the accounting, so event allocations get accounted for
> the memcg of
> the event producer process, even though the misbehaving process is the listener.
> The event allocations won't be freed if the producer exits, only if
> the listener exists.
> Nevertheless, it is still better to account event allocations to memcg
> of producer
> process and not to root memcg, because heuristically producer is many
> time in the
> same memcg as the listener. For example, this is the case with listeners inside
> containers that listen on events for files or mounts that are private
> to the container.
> <\suggest rephrase>

Well, if we're nitpicking ...

Due to the current design of kmemcg, the event allocation is accounted to
the memcg of the process producing the event, even though the misbehaving
process is the listener.  The event allocations won't be freed if the
producer exits, only if the listener exits.  Nevertheless, it is still
better to account event allocations to the producer's memcg than the
root memcg, because the producer is frequently in the same memcg as
the listener.  For example, this is the case with listeners inside
containers that listen to events for files or mounts that are private
to the container.