Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1310815imm; Wed, 15 Aug 2018 15:26:52 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzK1NDHzybWnqYC/VGGvUluBHtqyAweE+ha8ViFgD+PvZrV7SM7QhCOtHA2b1g42z/RVVwe X-Received: by 2002:a17:902:6a83:: with SMTP id n3-v6mr26112279plk.246.1534372012933; Wed, 15 Aug 2018 15:26:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534372012; cv=none; d=google.com; s=arc-20160816; b=aKFRkA1KoVHyeT8uN8Rh9PdyZJ8Kh9uTFRny4JA8FsVHdAGhTciqi746hWSL/WgxUX ggcAOpVceAnWLSqU9zpsI32mFnUElbwlRDZMY8Q3d+G1I7udKN59jBRYjiy+Jseorhgr j5+4QXP9XNeA61+INhDvKcqkisxHoasMtrTn9wrTrqw5RJCUMAU9ziN+CLPBVDqH5IA2 LkSLD2cQubsDEARgIeNPfg2ST+agrEMvy1Ij4col1VYWmOEdDGUM6UJh1qj/+bcXsGyf tiQWgD0mlAzS9jhO7je9SuowOpL13ISWD2nXrXj0+CHcsj+RMSiPl1+pkPsl29VLKFve c+9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=4h9kAQnQO289x5Rjs+gV5/4dfZRdoWZarOP2EBbgRRI=; b=0QCUdXNtPeL545gjNBxSutGxdrOJmcuYtjNv8lTH8HKcGa39NlF3jyDzTVrXJEWtD9 ubx4CS+vgi2pN6uO1cYOTmn/Who8dLzNuMsRNl0a8QLDcEyyFWhxEocLHgfwU7f2Kk7N Kv/c7cGT5qkhtpjnuVq29LAA36nGtasasive+VpOm7Fb+Fk70EDA1j4UzIEwXLVrjz4W 5tWbwnIUpnNcOiDy/lNSSQwjYJyKK0+3o4Hxk3Mkm5vZMVP1F+5ZKENLZ8ntb6e7YFU6 CGHs2BYreaCxDX9GOGiHstOIu1vQtYKvG/UrN0mXC+u8VZH0qyHzs1SPJyrHO/SmWBSb zmbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o24-v6si20129717pll.247.2018.08.15.15.26.37; Wed, 15 Aug 2018 15:26:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728002AbeHPBTU (ORCPT + 99 others); Wed, 15 Aug 2018 21:19:20 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38642 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727610AbeHPBTU (ORCPT ); Wed, 15 Aug 2018 21:19:20 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 37A1CBD8; Wed, 15 Aug 2018 22:25:12 +0000 (UTC) Date: Wed, 15 Aug 2018 15:25:11 -0700 From: Andrew Morton To: Shakeel Butt Cc: Michal Hocko , Johannes Weiner , Vladimir Davydov , Jan Kara , Greg Thelen , Amir Goldstein , Roman Gushchin , Alexander Viro , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v8 0/2] Directed kmem charging Message-Id: <20180815152511.3ea63aa54c5fac0bfe9370da@linux-foundation.org> In-Reply-To: <20180627191250.209150-1-shakeelb@google.com> References: <20180627191250.209150-1-shakeelb@google.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Jun 2018 12:12:48 -0700 Shakeel Butt wrote: > The Linux kernel's memory cgroup allows limiting the memory usage of > the jobs running on the system to provide isolation between the jobs. > All the kernel memory allocated in the context of the job and marked > with __GFP_ACCOUNT will also be included in the memory usage and be > limited by the job's limit. > > The kernel memory can only be charged to the memcg of the process in > whose context kernel memory was allocated. However there are cases where > the allocated kernel memory should be charged to the memcg different > from the current processes's memcg. This patch series contains two such > concrete use-cases i.e. fsnotify and buffer_head. > > The fsnotify event objects can consume a lot of system memory for large > or unlimited queues if there is either no or slow listener. The events > are allocated in the context of the event producer. However they should > be charged to the event consumer. Similarly the buffer_head objects can > be allocated in a memcg different from the memcg of the page for which > buffer_head objects are being allocated. > > To solve this issue, this patch series introduces mechanism to charge > kernel memory to a given memcg. In case of fsnotify events, the memcg of > the consumer can be used for charging and for buffer_head, the memcg of > the page can be charged. For directed charging, the caller can use the > scope API memalloc_[un]use_memcg() to specify the memcg to charge for > all the __GFP_ACCOUNT allocations within the scope. This patchset is not showing signs of having been well reviewed at this time. Could people please take another look?