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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D634C433F5 for ; Mon, 31 Jan 2022 18:00:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D03B8D0017; Mon, 31 Jan 2022 13:00:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 77E828D0001; Mon, 31 Jan 2022 13:00:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 620128D0017; Mon, 31 Jan 2022 13:00:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 541B08D0001 for ; Mon, 31 Jan 2022 13:00:38 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 073C0978FF for ; Mon, 31 Jan 2022 18:00:38 +0000 (UTC) X-FDA: 79091347356.09.A205EA0 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf13.hostedemail.com (Postfix) with ESMTP id 9C2EF20008 for ; Mon, 31 Jan 2022 18:00:37 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id b9so28503732lfq.6 for ; Mon, 31 Jan 2022 10:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZDAib+Bb/dH824cDSeLWITIJZuwoFHO7+dlyhfyg7SU=; b=bnGr1AtWDiuxZ4vCWPPtTrf0rCqdtKwtwCLDhRqdlmk/VByNX7ZDiYGlLu9UpojJuk cmrsI6WYoRXCN5xMdZW/vwApSpcBGKGj/vyMWBkkg8/4ABU8qzFO8Z8Ytq+nyV8L5rAx bPz29zv8jlQQT4kwtfAsG28PDsrgq0akpP0/bJ47B8d+kCcbZMc6nvW/gDsEiDHlBPgR SpXeezyCMttodSaARcOLP4wnQZLtSA0c5gtAiq+gH1S+CkUz36zRT2ZhKOvy5O1UMhsg eyVEFe4mMhm1ogImTdcQh+c2UYLHF0DdNC/kApoDZHqKhHscWYijtUUJ2JjSYLbGGpMK p37Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZDAib+Bb/dH824cDSeLWITIJZuwoFHO7+dlyhfyg7SU=; b=fVjX5WtrAk8lmi+ijFxY10Ggoh5shaq8QdUYsot0KZ2o1EvqVM82NjcgLauHjfV1Qn tL4Ad0IujzTtUedn2YJV7YSQFlFAjVbOS8Az/elz1JHLw2On8MwwM77zGQpFQdtBCNHo paG2y4KyNRreCUhQiT6aytH1kubKF4aRez8TZTOkYB4TVX/J7PGlzTbnOaCzJ6wn/ZBX xJi/1OaltqRT+6Woyb6EqGTcvbNCjiLIVl6JcgMLw4/yNFwunr6Qc3SXkxwMmhszHSD4 YjkooN42buY8rmJQYq5H8YXPuQVGhHHtTuw6huGV8qlHIxSwU28UzsAIoGRVkkjqKeUt eV1w== X-Gm-Message-State: AOAM532hAo5VejMxHb5p+sB1rFd8VOkCTOV8a3Yzx0rSLrsaU5hxDiDl ZORo/R5YjzhLcpbVgfARIH9Nq+giYBtcCLkprI50RQ== X-Google-Smtp-Source: ABdhPJxQznG399o4FeIp4grPFm8gWblqBKSsK5BWSTEtUQHPIYYYdo+jP7kOqfui2OPLfGhyyZPibpA0rS68i8bZLzs= X-Received: by 2002:a05:6512:3e10:: with SMTP id i16mr1911241lfv.184.1643652035654; Mon, 31 Jan 2022 10:00:35 -0800 (PST) MIME-Version: 1.0 References: <20211001190938.14050-1-longman@redhat.com> <20211001190938.14050-2-longman@redhat.com> <95ba1931-e9c9-45c3-b080-d28f2ad368a7@redhat.com> <9abc9cb8-8734-90b0-c495-8df89c7bb579@redhat.com> In-Reply-To: <9abc9cb8-8734-90b0-c495-8df89c7bb579@redhat.com> From: Shakeel Butt Date: Mon, 31 Jan 2022 10:00:24 -0800 Message-ID: Subject: Re: [PATCH 1/3] mm, memcg: Don't put offlined memcg into local stock To: Waiman Long Cc: Roman Gushchin , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Vlastimil Babka , LKML , Cgroups , Linux MM , Muchun Song Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 9C2EF20008 X-Stat-Signature: ui5mzhi354ouru747s1i84uwihpotxsy Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bnGr1AtW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspam-User: nil X-HE-Tag: 1643652037-404349 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 Mon, Jan 31, 2022 at 9:25 AM Waiman Long wrote: > > On 1/31/22 12:19, Roman Gushchin wrote: > > On Mon, Jan 31, 2022 at 12:15:19PM -0500, Waiman Long wrote: > >> On 1/31/22 12:09, Waiman Long wrote: > >>> On 1/31/22 12:01, Roman Gushchin wrote: > >>>> On Sun, Jan 30, 2022 at 10:55:56PM -0500, Waiman Long wrote: > >>>>> On 10/1/21 19:51, Roman Gushchin wrote: > >>>>>> On Fri, Oct 01, 2021 at 03:09:36PM -0400, Waiman Long wrote: > >>>>>>> When freeing a page associated with an offlined memcg, refill_stock() > >>>>>>> will put it into local stock delaying its demise until another memcg > >>>>>>> comes in to take its place in the stock. To avoid that, we now check > >>>>>>> for offlined memcg and go directly in this case to the slowpath for > >>>>>>> the uncharge via the repurposed cancel_charge() function. > >>>>>> Hi Waiman! > >>>>>> > >>>>>> I'm afraid it can make a cleanup of a dying cgroup slower: for every > >>>>>> released page we'll potentially traverse the whole cgroup tree and > >>>>>> decrease atomic page counters. > >>>>>> > >>>>>> I'm not sure I understand the benefits we get from this change which > >>>>>> do justify the slowdown on the cleanup path. > >>>>>> > >>>>>> Thanks! > >>>>> I was notified of a lockdep splat that this patch may help to prevent. > >>>> Would you mind to test this patch: > >>>> https://www.spinics.net/lists/cgroups/msg31244.html ? > >>>> > >>>> It should address this dependency. > >>> Thanks for the pointer. I believe that your patch should be able to > >>> address this circular locking dependency. > >>> > >>> Feel free to add my > >>> > >>> Reviewed-by: Waiman Long > >> BTW, have you posted it to lkml? If not, would you mind doing so? > > Not yet. > > > > I was waiting for Alexander to confirm that it resolves the originally reported > > issue. I just pinged him, will wait for tomorrow and post the patch in any case. > > > > Thanks! > > I see. This is not a problem that is easily reproducible. You need to > hit the right timing for the lockdep splat to appear. I agree here. The patch on its own has merits as it is reducing dependency on an unrelated lock.