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 093B0C433E0 for ; Fri, 15 May 2020 16:22:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C0CD2206D8 for ; Fri, 15 May 2020 16:22:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="aohSNYso" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C0CD2206D8 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 59C2D8E0005; Fri, 15 May 2020 12:22:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 525368E0001; Fri, 15 May 2020 12:22:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C5A38E0005; Fri, 15 May 2020 12:22:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id 1EDBD8E0001 for ; Fri, 15 May 2020 12:22:40 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D301C18057FFC for ; Fri, 15 May 2020 16:22:39 +0000 (UTC) X-FDA: 76819471638.02.whip11_6e84415af450c X-HE-Tag: whip11_6e84415af450c X-Filterd-Recvd-Size: 4899 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Fri, 15 May 2020 16:22:39 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id 202so2317961lfe.5 for ; Fri, 15 May 2020 09:22:39 -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=LwkHsen3NI9Qjxc8I+4g+FNh2Cs/D3EN1SDGWhqmxT8=; b=aohSNYsozE1gmyNt6a/bn8p591nfusDxfsuZvl6ankPpMCbYC99qbtKvt5NCGEakzU p7zkMnAUWEiSnhbKL/KRZBv1d7Dg3YJO+zmwtNfTThMwsRi7DEFGQjyIRoUFzlVHjc8p Dua2yaPxAQk9gtoMWnKgcgnm8pYEumr6+/iGbqoVphcwZ3s3lBUgnPStjR349BAuYVN6 Qd3+dkNmId7D6L8XTOAGxIJvsWmurSbhfQgcAqcIwC1E1V4fY3uf3pQms06iqbxnwCn3 ks1X7eTOkQRetzceSzg6MVptj7ipgCT8dKXcC75kXbqKVlanO+uYBTWa8P2ZHk0fxJoD yKpg== 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=LwkHsen3NI9Qjxc8I+4g+FNh2Cs/D3EN1SDGWhqmxT8=; b=lDguyThrLmT8cDPza8hE09JPIPOHEHS6vCrUXKrzpx6l95768oOLwtwPjKMgJjwFlP FVNHlL/oC3O1KnpwOlyw8WGvGlEhqkUmBkX1THEKHAC244C1t17FfwuDreiZgUs7PZRs R96imxm0ZZ99C7XSKHu8uAWfv9EZG7iLCiIXHj/OmZw/ok2qTgLRe0Ku9+TYOZ1pnG1b l5TW2p9Vxu280ldOHcRM+PO6Qjbt+N0GVkIHs31/AjIKSinkhxsc4iYX/2Ro8EbMc8Yp ravw+uZ8OcpNRnDp20ap6wlk2g+FM0HBQ35UQFHt+J8nlob/61FGuchMFm+iuM5fbmvo 0WEg== X-Gm-Message-State: AOAM532Eq6mwuAAMDz/xKe3Om2CbAZ4rQoSrnfU1cuE+Zz6HK7n6qWZO y/sGeZO6N1/OV8vgY1EaRGaM8liSN5PM4W779Zv23A== X-Google-Smtp-Source: ABdhPJwtHDG5d0ionxp8evYgrtSGB+uXgAcoNWPS8OnV64FG0RF2o/3NiHh9jk2ZXuaOYY278V/ZOZLXtF0SZD3dSro= X-Received: by 2002:a19:c85:: with SMTP id 127mr2957442lfm.189.1589559757341; Fri, 15 May 2020 09:22:37 -0700 (PDT) MIME-Version: 1.0 References: <20200513090502.GV29153@dhcp22.suse.cz> <76f71776-d049-7407-8574-86b6e9d80704@huawei.com> <20200513112905.GX29153@dhcp22.suse.cz> <3a721f62-5a66-8bc5-247b-5c8b7c51c555@huawei.com> <20200513161110.GA70427@carbon.DHCP.thefacebook.com> <20e89344-cf00-8b0c-64c3-0ac7efd601e6@huawei.com> <20200514225259.GA81563@carbon.dhcp.thefacebook.com> <20200515065645.GD29153@dhcp22.suse.cz> <20200515083458.GK29153@dhcp22.suse.cz> In-Reply-To: <20200515083458.GK29153@dhcp22.suse.cz> From: Shakeel Butt Date: Fri, 15 May 2020 09:22:25 -0700 Message-ID: Subject: Re: [PATCH v2] memcg: Fix memcg_kmem_bypass() for remote memcg charging To: Michal Hocko Cc: Zefan Li , Roman Gushchin , Johannes Weiner , Vladimir Davydov , Cgroups , Linux MM , Andrew Morton 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: On Fri, May 15, 2020 at 1:35 AM Michal Hocko wrote: > > On Fri 15-05-20 16:20:04, Li Zefan wrote: > > On 2020/5/15 14:56, Michal Hocko wrote: > > > On Thu 14-05-20 15:52:59, Roman Gushchin wrote: > [...] > > >>> I thought the user should ensure not do this, but now I think it makes sense to just bypass > > >>> the interrupt case. > > >> > > >> I think now it's mostly a legacy of the opt-out kernel memory accounting. > > >> Actually we can relax this requirement by forcibly overcommit the memory cgroup > > >> if the allocation is happening from the irq context, and punish it afterwards. > > >> Idk how much we wanna this, hopefully nobody is allocating large non-temporarily > > >> objects from an irq. > > > > > > I do not think we want to pretend that remote charging from the IRQ > > > context is supported. Why don't we simply WARN_ON(in_interrupt()) there? > > > > > > > How about: > > > > static inline bool memcg_kmem_bypass(void) > > { > > if (in_interrupt()) { > > WARN_ON(current->active_memcg); > > return true; > > } > > Why not simply > > if (WARN_ON_ONCE(in_interrupt()) > return true; > > the idea is that we want to catch any __GFP_ACCOUNT user from IRQ > context because this just doesn't work and we do not plan to support it > for now and foreseeable future. If this is reduced only to active_memcg > then we are only getting a partial picture. > There are SLAB_ACCOUNT kmem caches which do allocations in IRQ context (see sk_prot_alloc()), so, either we make charging work in IRQ or no warnings at all.