From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7080AC11D20 for ; Thu, 20 Feb 2020 21:14:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 302EC20679 for ; Thu, 20 Feb 2020 21:14:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="F18pix32" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 302EC20679 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B086D6B0005; Thu, 20 Feb 2020 16:14:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8E26B0006; Thu, 20 Feb 2020 16:14:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F5846B0007; Thu, 20 Feb 2020 16:14:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0050.hostedemail.com [216.40.44.50]) by kanga.kvack.org (Postfix) with ESMTP id 847F46B0005 for ; Thu, 20 Feb 2020 16:14:30 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3B38F2491 for ; Thu, 20 Feb 2020 21:14:30 +0000 (UTC) X-FDA: 76511759100.26.jelly30_2743ddf0ddb35 X-HE-Tag: jelly30_2743ddf0ddb35 X-Filterd-Recvd-Size: 5450 Received: from mail-vs1-f66.google.com (mail-vs1-f66.google.com [209.85.217.66]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Feb 2020 21:14:29 +0000 (UTC) Received: by mail-vs1-f66.google.com with SMTP id p14so3644471vsq.6 for ; Thu, 20 Feb 2020 13:14:29 -0800 (PST) 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=ktuN17gmiqlKE/I4GYw0sVSSXcxY6RgmY2JpLivgLB4=; b=F18pix32o4K9RJdf3Ge/L+3NgYmCrMt8y8HZvV7+XlYsyAkPvClxTvbluEB0EVBNoS 9+5z76T7v66vZmEXr5Fa4C/xKMwaD8hX4VGSvj8eZYiZhBSzZACB9ZEorWg+DVYqunsU RFZh8hBBTc1wggIAqZQ8fPUMT+E336fsvX6EBArXEQTHs+Q6GmOMMeP/F2BbTvjRp3yP 38VdoqNYXn7SI2xBaY09WCr+qilbJTaiNEXxjdzAV9AQQ9JUqPWXdte/fUYO6KBM0A0C FpO9xdOiWJLrQSK1axpfwR42CRT4jmUVITnSPFR0HZjupTxdP02SIacYzr13JUNGmFkW yvWw== 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=ktuN17gmiqlKE/I4GYw0sVSSXcxY6RgmY2JpLivgLB4=; b=J4f10rlfcRtfUzkg1bMW5ryzQibPZJNkS0r0JGm48SrhmoPGwqyIQG05u76BRo0lB3 Pldmauhxo1gAVyyNlgW8slfbl9/PBrqZFMA8aiL/reFfAJINyKrObYj7TuHt2NuPEyax lzVQ84A8aBWxvSG2TkAyYciA8TI+h4cT4173sOgVDhIfG9GXxvzcX2xI72Ee0jB0aTlk 0GF4vWt8NVfbMpXDuIjAS0C+ojuqt98F0dbeQl+5RpDB5Hp+sg6lUfcbx5KW4/ugy0LR wP15Zbxp1epsC87o3p7eIWKPARW7jsHX4RnQ1XV07XaX/C0H1bevwpHRE71dySXO5Ekm Tq0w== X-Gm-Message-State: APjAAAVd3LGoy4UE4uzbHapsJgvYfqSXq0QWu1xg1rhSKXsvJBlbxVYB gI8couxMrzcHIG3I+c1iNG3SQ8tENrlgG67QAVlbzA== X-Google-Smtp-Source: APXvYqz36y/bjwSmf4YA26Hzf3Na7uNT93GpIDlzKWJuYGCdukm8wFMJ3Hp3KJ5ZZyx0QkIHmybvHgs4qnksLGR44Kc= X-Received: by 2002:a67:fbcf:: with SMTP id o15mr17597426vsr.13.1582233268659; Thu, 20 Feb 2020 13:14:28 -0800 (PST) MIME-Version: 1.0 References: <0a27b6fcbd1f7af104d7f4cf0adc6a31e0e7dd19.1582216294.git.schatzberg.dan@gmail.com> <20200220210344.GK54486@cmpxchg.org> In-Reply-To: <20200220210344.GK54486@cmpxchg.org> From: Shakeel Butt Date: Thu, 20 Feb 2020 13:14:17 -0800 Message-ID: Subject: Re: [PATCH v3 2/3] mm: Charge active memcg when no mm is set To: Johannes Weiner Cc: Dan Schatzberg , Jens Axboe , Tejun Heo , Li Zefan , Michal Hocko , Vladimir Davydov , Andrew Morton , Hugh Dickins , Roman Gushchin , Chris Down , Yang Shi , Thomas Gleixner , "open list:BLOCK LAYER" , open list , "open list:CONTROL GROUP (CGROUP)" , "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Johannes, On Thu, Feb 20, 2020 at 1:03 PM Johannes Weiner wrote: > > Hey Shakeel! > > On Thu, Feb 20, 2020 at 10:14:45AM -0800, Shakeel Butt wrote: > > On Thu, Feb 20, 2020 at 8:52 AM Dan Schatzberg wrote: > > > > > > memalloc_use_memcg() worked for kernel allocations but was silently > > > ignored for user pages. > > > > > > This patch establishes a precedence order for who gets charged: > > > > > > 1. If there is a memcg associated with the page already, that memcg is > > > charged. This happens during swapin. > > > > > > 2. If an explicit mm is passed, mm->memcg is charged. This happens > > > during page faults, which can be triggered in remote VMs (eg gup). > > > > > > 3. Otherwise consult the current process context. If it has configured > > > a current->active_memcg, use that. > > > > What if css_tryget_online(current->active_memcg) in > > get_mem_cgroup_from_current() fails? Do we want to change this to > > css_tryget() and even if that fails should we fallback to > > root_mem_cgroup or current->mm->memcg? > > Good questions. > > I think we can switch to css_tryget(). If a cgroup goes offline > between issuing the IO and the loop layer executing that IO, the > resources used could end up in the root instead of the closest > ancestor of the offlined group. However, the risk of that actually > happening and causing problems is probably pretty small, and the > behavior isn't really worse than before Dan's patches. Agreed. > > Would you mind sending a separate patch for this? AFAICS similar > concerns apply to all users of foreign charging. Sure and yes similar concerns apply to other users as well. > > As for tryget failing: can that actually happen? AFAICS, all current > users acquire a reference first (get_memcg_from_somewhere()) that they > assign to current->active_memcg. We should probably codify this rule > and do WARN_ON(!css_tryget()) /* current->active_memcg must hold a ref */ Yes, we should WARN_ON(). Shakeel