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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 075B6C433F5 for ; Sat, 2 Oct 2021 01:54:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 851DD61A7B for ; Sat, 2 Oct 2021 01:54:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 851DD61A7B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A5C246B006C; Fri, 1 Oct 2021 21:54:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0B7F6B0071; Fri, 1 Oct 2021 21:54:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FAE16B0072; Fri, 1 Oct 2021 21:54:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8415F6B006C for ; Fri, 1 Oct 2021 21:54:20 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3C65839BB6 for ; Sat, 2 Oct 2021 01:54:20 +0000 (UTC) X-FDA: 78649827480.12.4F4D319 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf12.hostedemail.com (Postfix) with ESMTP id C354410006B6 for ; Sat, 2 Oct 2021 01:54:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633139659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O0xoezi4Z/qOe9rLHxMxM8UOrRHkvWYCakknTRmKZYE=; b=L4OzxGCMpLspgfnkHdx/rKaUYqyDQLMoFZfS7wTquXSiK7k6Fz6Ttz9Olbgs9JH4+P6rXf kCvXVL5/ylpP2WL7YfqfwkzB5GM1m0p7/P38qf1Z7SFe0muyCsbZWQ0DcSVO7W4HXdN1oD AXoEC3Af8b6zrzej85x7SsvW/34S1Tk= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-51-DQ4t3QKFMnS5tRy5Gdy_pQ-1; Fri, 01 Oct 2021 21:54:16 -0400 X-MC-Unique: DQ4t3QKFMnS5tRy5Gdy_pQ-1 Received: by mail-qv1-f69.google.com with SMTP id ey7-20020a0562140b6700b00382cf3eb480so1067658qvb.22 for ; Fri, 01 Oct 2021 18:54:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=O0xoezi4Z/qOe9rLHxMxM8UOrRHkvWYCakknTRmKZYE=; b=Q80VVnADkh4E6wyapaGT0/RiTlci5UODSXnlikUkO08xWH8aoL5uimOckf8oEAKeft LiS6oxWnHPS298G+ecFopdtAinuwxlYOuYOnY92nLuS/guy2MnHtg8o0fQFYJWXE1UgO pwLrtzSlG9Il0Xj2Ze4M0zkxlF/oa6l2VggvFDfBJbq/CxT5ORef8CukMp9MN//5fUqW lfrBYBfc/AVm4q92MrEM3l2VJAMxwb3BgJ2JVj6f+x//yUDjwUV/t+bVOOBdV9cT5uiJ XAHCpGshun4N15vMxe2d5YKoZYuCN0Tn4vbLYDlTqxYSzK91L6sMXn7Tgxq6XgPOScGe 5uwQ== X-Gm-Message-State: AOAM533UGcV4yUW+uiDzJzgOsGHaYIMW24ODg7I64HApYP+5/Z5evmxk Wh7pRyziBVAuWv3Pp8SkH65a4To6Jqk/GrslTgqbULU/J8e2DWHG5R93OE/2kv2profVn4f8Ij0 8kRP6OZl+F4A= X-Received: by 2002:a0c:f094:: with SMTP id g20mr12055311qvk.55.1633139656506; Fri, 01 Oct 2021 18:54:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypmZTsFfQss8HzuioAd9a68ABkXlfCgwp7JFvKvJhWuAFJ3fhhyjrAnxkHYQyoxyzrSDDJJA== X-Received: by 2002:a0c:f094:: with SMTP id g20mr12055294qvk.55.1633139656287; Fri, 01 Oct 2021 18:54:16 -0700 (PDT) Received: from llong.remote.csb ([2601:191:8500:76c0::cdbc]) by smtp.gmail.com with ESMTPSA id v7sm3966408qkd.41.2021.10.01.18.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Oct 2021 18:54:16 -0700 (PDT) From: Waiman Long X-Google-Original-From: Waiman Long Subject: Re: [PATCH 1/3] mm, memcg: Don't put offlined memcg into local stock To: Roman Gushchin Cc: Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Vlastimil Babka , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt , Muchun Song References: <20211001190938.14050-1-longman@redhat.com> <20211001190938.14050-2-longman@redhat.com> Message-ID: <6296d44d-a728-973a-0fc3-b5e30a09f920@redhat.com> Date: Fri, 1 Oct 2021 21:54:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C354410006B6 X-Stat-Signature: b7wpbhpi3i4i6ujat3rxhzpdqcznz91m Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=L4OzxGCM; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf12.hostedemail.com: domain of llong@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=llong@redhat.com X-HE-Tag: 1633139659-381871 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/1/21 7:51 PM, 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. I am debugging a problem where some dying memcgs somehow stay around for a long time leading to gradual increase in memory consumption over time. I see the per-cpu stock as one of the places where a reference to a dying memcg may be present. Anyway, I agree that it may not help much. I am going to drop it if you think it is not a good idea. Cheers, Longman