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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 ED41AC433ED for ; Fri, 2 Apr 2021 17:30:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6405C61164 for ; Fri, 2 Apr 2021 17:30:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6405C61164 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A4B2D6B007E; Fri, 2 Apr 2021 13:30:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A224E6B0080; Fri, 2 Apr 2021 13:30:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89C0B6B0081; Fri, 2 Apr 2021 13:30:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id 6D5A26B007E for ; Fri, 2 Apr 2021 13:30:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 305821AB5D for ; Fri, 2 Apr 2021 17:30:17 +0000 (UTC) X-FDA: 77988115674.08.B536D1B Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf13.hostedemail.com (Postfix) with ESMTP id 3AFAAE00010F for ; Fri, 2 Apr 2021 17:30:15 +0000 (UTC) Received: by mail-qk1-f170.google.com with SMTP id 7so5850660qka.7 for ; Fri, 02 Apr 2021 10:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DRNvD2RZwkvfxZeMQahLHViX8Lbm4hnuuu0I+GZK54A=; b=MTdGyVvrDep3yoWnXlj9PW8WZwL5t7qwsdbnOchYfmYvMB2HUQkpdBTfNKn6fJKQTY 2TDVRP82/IV2Fywygt2Dey0ONke+llzbJLktor50u+zzHL+XkfLcgfRMoXqlFyMfyfKy YU/lXsmW/fa8KSoomYVtceqARiTNj6oDrKifhrKAYYoJiW6fnUWPwb0g954VBl7vL1/L /EXlnc5uw9hmJnyO7a7pyJ/fnqyB4dtjoYXUGOSeXWubo9Fnthk2PLVIYOoIC6iiGe6X at5ilZSWTgG/j417bvW0cyiQvdFx3CV08jt3+js+21fwiuL8HPuvWyzh+wQbfeAGzs89 jS1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DRNvD2RZwkvfxZeMQahLHViX8Lbm4hnuuu0I+GZK54A=; b=dN+moyGxLAe99A/1YeJMlNco8ebQ8jthI/DJ8zP7t6kDR82qCDa5332dYZlarbaH+x eaINxbJkM58Z5Z7z65VvTL24HoqcICDnrSJxxs6kuR5WiuNm+swhz/WPBUzpIz6sGAGH C3mDJwg7NKDcX6rgODNOB/Ju1uIPCHR47ngnAeg44rh/9hY6KTQNJc3LD20zl1V3WpTo Owb+JQ+9jojkbX73LX3bTXm6yarDvwawIiHL1MpC9wfPPI5QQs/NV/F2fViGbUIIjcYI dJ7u3rapxCZPZLOd08eVR2x5nq6QmUz1WLovbBB4ObgvEszB5Va8ektG0JHeTOK/vqWy iH8Q== X-Gm-Message-State: AOAM531oBnwzNIVYg/sP0NnFvyNHaNOUaG+Uce+q2hDe9P5EbuBJLK7L 1+JNwLYuX6NXt+mQm9XP5fjodQ== X-Google-Smtp-Source: ABdhPJyrSrnm5Q9XdnLTCYqtUFj82QUxNm5rK0YYwf4tJ6SJQd++2gJQRfp7gSQwdsMUzboInWu8iw== X-Received: by 2002:a05:620a:11a4:: with SMTP id c4mr13818945qkk.313.1617384615843; Fri, 02 Apr 2021 10:30:15 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:8ca7]) by smtp.gmail.com with ESMTPSA id n140sm7682859qka.124.2021.04.02.10.30.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Apr 2021 10:30:15 -0700 (PDT) Date: Fri, 2 Apr 2021 13:30:13 -0400 From: Johannes Weiner To: Shakeel Butt Cc: Muchun Song , Roman Gushchin , Greg Thelen , Michal Hocko , Andrew Morton , Vladimir Davydov , LKML , Linux MM , Xiongchun duan Subject: Re: [External] Re: [RFC PATCH 00/15] Use obj_cgroup APIs to charge the LRU pages Message-ID: References: <20210330101531.82752-1-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 3AFAAE00010F X-Stat-Signature: 4d5zn9uuhz7jp91k6p1tpazp1iifyczd Received-SPF: none (cmpxchg.org>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mail-qk1-f170.google.com; client-ip=209.85.222.170 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617384615-829860 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 Thu, Apr 01, 2021 at 10:15:45AM -0700, Shakeel Butt wrote: > On Thu, Apr 1, 2021 at 9:08 AM Muchun Song wrote: > > > [...] > > > The zombie issue is a pretty urgent concern that has caused several > > > production emergencies now. It needs a fix sooner rather than later. > > > > Thank you very much for clarifying the problem for me. I do agree > > with you. This issue should be fixed ASAP. Using objcg is a good > > choice. Dying objcg should not be a problem. Because the size of > > objcg is so small compared to memcg. > > > > Just wanted to say out loud that yes this patchset will reduce the > memcg zombie issue but this is not the final destination. We should > continue the discussions on sharing/reusing scenarios. Absolutely. I think it's an important discussion to have. My only concern is that Muchun's patches fix a regression, which admittedly has built over a few years, but is a regression nonetheless that can leave machines in undesirable states and may require reboots. The sharing and reuse semantics on the other hand have been the same since the beginning of cgroups. Users have had some time to structure their requirements around these semantics :-) If there were a concrete proposal or an RFC on the table for how sharing and reusing could be implemented, and this proposal would be in direct conflict with the reparenting patches, I would say let's try to figure out a way whether the bug could be fixed in a way that is compatible with such another imminent change. But we shouldn't hold up a bug fix to start planning a new feature.