Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5539692imm; Tue, 26 Jun 2018 13:07:39 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKx8kRy5H/H0fx8jMVCSABfAObE0QycdE38FwMjRprnf05K7XCcAb55ZjMa4U4tvVrf6mTJ X-Received: by 2002:a17:902:714e:: with SMTP id u14-v6mr3022549plm.289.1530043659943; Tue, 26 Jun 2018 13:07:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530043659; cv=none; d=google.com; s=arc-20160816; b=05uFjLJdoPzmE3EyjcH0zLrxD/y4wn1HBUYg0jISVEIwg0QgyueV0Ue76VxtVTT1/J +lfsqdgnC9MunEmLBoztuBFoAGyTMV0drkVy59K/9tys/wfNS/PRb3yqmqKDjMWqaKnt uKSFFBgIGzgF35lHcDh//aek4Gp8+4H5aNQhhgtP7Hu5cRi0IK+JROmk/Z/UGDL5SkcZ YwsmKAQsP+apGYRbucmjOhM+1X/6nDCAvbd89VoXQ7+B38objOkiDR6Cy2N8b0aVhUs7 GnHY61y6QJV1XVoSpynX7gtumIS/ljNWLz2JwhBGWJlDdsHIAWTMEUFq30ZE4Jg38alj lJbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=X7FVMGJWHOZkxWyXcdo36JkO3xwzZOdCUPu5WvzQPEg=; b=uRMyOj/vUPqH51tXC84WgmYT7ZImw/53QpG3AG6tMMIvKA/kae/L/qiDU3qvxZOf9w W5wFKMs8RmfwrtMw3ln/+kO0lQ2gzF3JcJ564O+xbBNkgJ1kSxSuu0o22hXl9lcRbGoR B/ta+S2Y8pAgh92j/fp2nlRWf86SJnI3TGbwpdtTqvsdSSU/PCqmS0zB8UJGGIAp9Jqd SEO3MfnPq8CFub1IQSX+9GtKqbtH5BsiU6dv8krW5IPEvXJNGIi9OURPSS+C38GJazOI Q3N7VrWIL97DrR+5606FQ8O6rFu5LXKIXtBrm0tUG76NVbwvgUk9mQUy9XUhajt200dx W1+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Egiy5RCh; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j84-v6si2319002pfj.79.2018.06.26.13.07.25; Tue, 26 Jun 2018 13:07:39 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=Egiy5RCh; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933051AbeFZUGL (ORCPT + 99 others); Tue, 26 Jun 2018 16:06:11 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:37915 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754979AbeFZUGJ (ORCPT ); Tue, 26 Jun 2018 16:06:09 -0400 Received: by mail-wr0-f196.google.com with SMTP id e18-v6so18450045wrs.5 for ; Tue, 26 Jun 2018 13:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X7FVMGJWHOZkxWyXcdo36JkO3xwzZOdCUPu5WvzQPEg=; b=Egiy5RCh6DAmIf2HiXn77yjfDD3Xjah/greibEYUXcxxlqczW0R+a4TtrKJb0sYqRD j+3fhiqOQ8eOyscy+60SO1yTfNZxJPD4/cOPaCwPUBm5d9MPB9srwBSbaTZ7QUasJ7lv Er6YuGbTJ07eGC7achVVqTnMGxK9UPrhGBPeYOOPOs9dy/PR2Yth+OH8a6M8e5CcMuuz 0gb384MUTDY8o6a3n8i2Y9lCfdURGuqkeb4Tfx5upQuOZUdd80jdNt0QtYtrpUrp6uIz r9MSGR+l2r1FmroiqPAwaFum4mSsjvQUD2iGYJtaFLyoM9b2sSKlHSm5xLEsl0NXtz0N zLDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X7FVMGJWHOZkxWyXcdo36JkO3xwzZOdCUPu5WvzQPEg=; b=kSm9NDOFM79/dtuVb7k0t7IiJkKc74vr55u9ovgZ/zIC+2fE1K5C7t/PRZSpPlyJ4T +f6ipQKCIMcpBG3WoOG1rWht1Fyy4fFYJXVBDvZ8/tIYmen0zQFfDouwvtSV5KqbH02p n+nptiMKt7DyqQ2M3jxWzW6aOUYwxMrGcsVFF4960/ZNh8d7J4wCkuJfXVlqMjtM06Bg I7Y7PMxhImCv9CdCalXUzflQpdveRIPV0Spb7JgrIxOW6Wa+iDyqEJwaoifyW0Jcq+wu amOnGwfWmTcsS0QVFwNGjxoiRW/o5L4YSSKgPb26/3eJuAimfv4txk8WMYMjOEymm+k1 YYvQ== X-Gm-Message-State: APt69E2nRHQuGP6fs/7CBhUeLdhQTAZ7YjUn3OuXgPtbuStLVuN3qr29 Oyj5FI231pYKhMeiwvYR76GVlmgm3Kyd5wgorMoCqA== X-Received: by 2002:adf:e48e:: with SMTP id i14-v6mr2861555wrm.8.1530043567387; Tue, 26 Jun 2018 13:06:07 -0700 (PDT) MIME-Version: 1.0 References: <20180625230659.139822-1-shakeelb@google.com> <20180625230659.139822-2-shakeelb@google.com> <20180626190619.GB3958@cmpxchg.org> In-Reply-To: <20180626190619.GB3958@cmpxchg.org> From: Shakeel Butt Date: Tue, 26 Jun 2018 13:05:55 -0700 Message-ID: Subject: Re: [PATCH 1/2] fs: fsnotify: account fsnotify metadata to kmemcg To: Johannes Weiner Cc: Andrew Morton , Michal Hocko , Vladimir Davydov , Jan Kara , Greg Thelen , Amir Goldstein , Roman Gushchin , Alexander Viro , LKML , Cgroups , linux-fsdevel , Linux MM , Jan Kara Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 26, 2018 at 12:03 PM Johannes Weiner wrote: > > On Mon, Jun 25, 2018 at 04:06:58PM -0700, Shakeel Butt wrote: > > @@ -140,8 +141,9 @@ struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group, > > struct inode *inode, u32 mask, > > const struct path *path) > > { > > - struct fanotify_event_info *event; > > + struct fanotify_event_info *event = NULL; > > gfp_t gfp = GFP_KERNEL; > > + struct mem_cgroup *old_memcg = NULL; > > > > /* > > * For queues with unlimited length lost events are not expected and > > @@ -151,19 +153,25 @@ struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group, > > if (group->max_events == UINT_MAX) > > gfp |= __GFP_NOFAIL; > > > > + /* Whoever is interested in the event, pays for the allocation. */ > > + if (group->memcg) { > > + gfp |= __GFP_ACCOUNT; > > + old_memcg = memalloc_use_memcg(group->memcg); > > + } > > group->memcg is only NULL when memcg is disabled or there is some > offlining race. Can you make memalloc_use_memcg(NULL) mean that it > should charge root_mem_cgroup instead of current->mm->memcg? That way > we can make this site unconditional while retaining the behavior: > > gfp_t gfp = GFP_KERNEL | __GFP_ACCOUNT; > > memalloc_use_memcg(group->memcg); > kmem_cache_alloc(..., gfp); > out: > memalloc_unuse_memcg(); > > (dropping old_memcg and the unuse parameter as per the other mail) > group->memcg is only NULL when memcg is disabled (i.e. get_mem_cgroup_from_mm() returns root_mem_cgroup for offlined mm->memcg). Though group->memcg can point to an offlined memcg. If I understand you correctly this is what we want: 1. If group->memcg is NULL then __GFP_ACCOUNT is a noop i.e. memcg is disabled. 2. If group->memcg is root_mem_cgroup, then __GFP_ACCOUNT again is a kind of noop (charges to root_mem_cgroups are bypassed). 3. If group->memcg is offlined memcg, then make __GFP_ACCOUNT noop by returning root_mem_cgroup from get_mem_cgroup_from_current(). 4. Else charge group->memcg. This seems reasonable. After your Ack and Amir's or Jan's answer to the nesting query, I will resend the next version of this patch series. In future if we find any use-cases of memalloc_use_memcg nesting then we can make it work for nesting. thanks, Shakeel