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=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 D85B8C433E0 for ; Fri, 5 Feb 2021 11:05:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3BBBD64E34 for ; Fri, 5 Feb 2021 11:05:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BBBD64E34 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A0AB76B0005; Fri, 5 Feb 2021 06:04:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BC386B006C; Fri, 5 Feb 2021 06:04:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D1FC6B006E; Fri, 5 Feb 2021 06:04:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id 750F26B0005 for ; Fri, 5 Feb 2021 06:04:59 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3B5BA180AD806 for ; Fri, 5 Feb 2021 11:04:59 +0000 (UTC) X-FDA: 77783931918.29.mice53_1f00d73275e4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 1E9E618086CA8 for ; Fri, 5 Feb 2021 11:04:59 +0000 (UTC) X-HE-Tag: mice53_1f00d73275e4 X-Filterd-Recvd-Size: 5375 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Feb 2021 11:04:58 +0000 (UTC) Received: by mail-pj1-f41.google.com with SMTP id s24so3419234pjp.5 for ; Fri, 05 Feb 2021 03:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G84XgAXTIB9kxrWKppVfB7bhTavqUSYTbC5KVvLAP6g=; b=Gy+FulpQZ1ltev+PwnM5KcE1+7GoQk9sA8tu5+DNBMHtUciX/ITccny0i5NJW0w7eN lGEzSPoFo9+wKYG2McWRVBm1Kmpq6kfFh5PhvWeihcnbhdOKklU4ILERzeHkx8EzNmk9 i2SQGg/4Ym7WsDWEKQLWRn9qEI/hHlU4td7Qd3EXvUsobrhBYid/LeaWZ8/UwedTf6ma cuUScuIGTGY4silbfwJ4wVkSA05+vDlJGfoGiUQxtRa8IE3fYnmbwWcJe/el4NjtD/TZ KJRYPc5ncLHX3SwjBYlcNGi3Yu6fkNMxVNmGirHAS1yqLnmZH4X5TSdL5U/T6iQGFG+N ToyA== 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=G84XgAXTIB9kxrWKppVfB7bhTavqUSYTbC5KVvLAP6g=; b=ki22WkKat3dkY5Q6UY2os+YdxR8s1xQw/PbyuUyI+H3/CAvCVCfhMSIA+KC7WGV180 xK8ornoIP2Wljqqxxv1zCOZ0b4dKz9Ci/mAJ/CaPmnnF+0Zdd+uiCflUnQOiYSFKRGqZ cLfgemyleJpPjcgp1mdim5DguGM/TeirHUYxVal6SdGnByCnJUF4is3Ei1HG5RQlToUL TfS7Fy73HqHhHFd3th8G5zw4LQILGr+78wxczHY5QP3BwT9zuDt+594y82UkdVpyM1xs lqVseBs/84eeiihrJ37jzBb7jfY/xlwwTRoE/mjsrzWQJJ/bLQe5FEK6gQtOIMS99QPG PrsQ== X-Gm-Message-State: AOAM530n+mtSQl/s2D32nMY1Kaw+D8tsjYQDKF2ntrOGvgmwtu81Vpk+ +tyDex1lF/XhTOQz9sowBgYF+7aVnO1TmGrEhQ317w== X-Google-Smtp-Source: ABdhPJww7F5WzQ1oqkJJpHPK2EsEFNrSMkvwZXanGafRo0NCNhE/HrOFxiP/gxTYPP/GIrJisIFxzklQWvXyhht6lNo= X-Received: by 2002:a17:90b:1096:: with SMTP id gj22mr3534837pjb.229.1612523097393; Fri, 05 Feb 2021 03:04:57 -0800 (PST) MIME-Version: 1.0 References: <20210205062310.74268-1-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Fri, 5 Feb 2021 19:04:19 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm: memcontrol: fix missing wakeup oom task To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Cgroups , Linux Memory Management List , LKML 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, Feb 5, 2021 at 6:21 PM Michal Hocko wrote: > > On Fri 05-02-21 17:55:10, Muchun Song wrote: > > On Fri, Feb 5, 2021 at 4:24 PM Michal Hocko wrote: > > > > > > On Fri 05-02-21 14:23:10, Muchun Song wrote: > > > > We call memcg_oom_recover() in the uncharge_batch() to wakeup OOM task > > > > when page uncharged, but for the slab pages, we do not do this when page > > > > uncharged. > > > > > > How does the patch deal with this? > > > > When we uncharge a slab page via __memcg_kmem_uncharge, > > actually, this path forgets to do this for us compared to > > uncharge_batch(). Right? > > Yes this was more more or less clear (still would have been nicer to be > explicit). But you still haven't replied to my question I believe. I > assume you rely on refill_stock doing draining but how does this address > the problem? Is it sufficient to do wakeups in the batched way? Sorry, the subject title may not be suitable. IIUC, memcg_oom_recover aims to wake up the OOM task when we uncharge the page. I see uncharge_batch always do this. I am confused why __memcg_kmem_uncharge does not. Both paths do the same thing (uncharge pages). So actually, this patch want to keep the two paths consistent. Thanks. > > > > > When we drain per cpu stock, we also should do this. > > > > > > Can we have anything the per-cpu stock while entering the OOM path. IIRC > > > we do drain all cpus before entering oom path. > > > > You are right. I did not notice this. Thank you. > > > > > > > > > The memcg_oom_recover() is small, so make it inline. > > > > > > Does this lead to any code generation improvements? I would expect > > > compiler to be clever enough to inline static functions if that pays > > > off. If yes make this a patch on its own. > > > > I have disassembled the code, I see memcg_oom_recover is not > > inline. Maybe because memcg_oom_recover has a lot of callers. > > Just guess. > > > > (gdb) disassemble uncharge_batch > > [...] > > 0xffffffff81341c73 <+227>: callq 0xffffffff8133c420 > > 0xffffffff81341c78 <+232>: jmpq 0xffffffff81341bc0 > > 0xffffffff81341c7d <+237>: callq 0xffffffff8133e2c0 > > So does it really help to do the inlining? I just think memcg_oom_recover is very small, inline maybe a good choice. Maybe I am wrong. > -- > Michal Hocko > SUSE Labs