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 E403BC43460 for ; Mon, 19 Apr 2021 21:11:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5511D611EE for ; Mon, 19 Apr 2021 21:11:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5511D611EE 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 646656B0070; Mon, 19 Apr 2021 17:11:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F6FC6B0071; Mon, 19 Apr 2021 17:11:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 470C36B0072; Mon, 19 Apr 2021 17:11:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id 2C4536B0070 for ; Mon, 19 Apr 2021 17:11:40 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DD5768249980 for ; Mon, 19 Apr 2021 21:11:39 +0000 (UTC) X-FDA: 78050363118.23.073CD47 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 96B0340002D0 for ; Mon, 19 Apr 2021 21:11:17 +0000 (UTC) Received: by mail-qk1-f175.google.com with SMTP id d19so1634792qkk.12 for ; Mon, 19 Apr 2021 14:11:38 -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=kPOgD6C7v2B3aEHjJMDvlRbbnpG5eAvY8t4HD5c6Yis=; b=UlWrQYGza8aibZnqSYH/OqcDuvVsUUVBQcgNrU+9I1ijvOfKSrXrmSPsfS3Q+ISSeU bLQphTkHmGtTjpITmZRb5yABkr0e+MyWqnDYelz/IzjLDJPkknb4yhiSISEAxkPVXuQ8 EbK7XbgKE94d6C/E5X7z3Wtr3KC5GhI8OSwlxl0XIbIMkrczsRO2ksmNhUKp5iy/AEWg crD3NfneUNuz6kHAtfpEfxWx2OrkJqA2tLKOOWX/Wbov8TyxF8/oS/VW74aqW4BdqGwO /dM3US/3owHiccUEwLP9jLRAJWTf5QOqAlhohiMnUCHMBUkOR+8Bb6p91ByyU68c6CJw j/mg== 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=kPOgD6C7v2B3aEHjJMDvlRbbnpG5eAvY8t4HD5c6Yis=; b=TgWn4PU5CLahATXA36/1SbuvA4jwca6Jx8tHMJ8g6Ruqr0ES15fXKPXFiGiynDWCa/ Q0bwVjty+WxO6xQuXDVuUfH0PEsbYMw6z+q8cQqq1iATi5BSLAqy1EQyrpysGczwrhBV 65FJwOE0G03WUXaU1dRR3iyu5ndtlchjENq1oSEfhz69l8to1blx4U+Mau7lTJCcLRkn byl2HM9Xo1jshrszz5oZh3+08l9kui75gJscBhW1Zgu3QIQ/LN2KJSUWpT1LJtQLJ4PE Xt6vmCPihytUQB3R47nzv6eRyrBUKEDJIS7tFIeRyU3cvtABar+ba+HRkCc/rVK+qbuk Oifw== X-Gm-Message-State: AOAM533exc85iKOPslDZxM+X0MbwWhA5FuZXh6FC8N1heBF4lvMcM3o3 4KI1+Xn2klyaa4QuF5/TW4fLGQ== X-Google-Smtp-Source: ABdhPJx+8QKA7AkE7vpCKAo17/CK+jq9lSJriGKPFMrlgLdPnOmxYyJw8UzQZ2lGMnMtW2XGNBWwEw== X-Received: by 2002:a37:9903:: with SMTP id b3mr1913227qke.17.1618866698526; Mon, 19 Apr 2021 14:11:38 -0700 (PDT) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id d207sm5796754qke.59.2021.04.19.14.11.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Apr 2021 14:11:38 -0700 (PDT) Date: Mon, 19 Apr 2021 17:11:37 -0400 From: Johannes Weiner To: Waiman Long Cc: Michal Hocko , Vladimir Davydov , Andrew Morton , Tejun Heo , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt , Muchun Song , Alex Shi , Chris Down , Yafang Shao , Wei Yang , Masayoshi Mizuma , Xing Zhengjun , Matthew Wilcox Subject: Re: [PATCH v4 1/5] mm/memcg: Move mod_objcg_state() to memcontrol.c Message-ID: References: <20210419000032.5432-1-longman@redhat.com> <20210419000032.5432-2-longman@redhat.com> <140444ea-14e7-b305-910f-f23fafe45488@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 96B0340002D0 X-Stat-Signature: tat5esnjo64ww4si9m163uc6czci1qw6 Received-SPF: none (cmpxchg.org>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mail-qk1-f175.google.com; client-ip=209.85.222.175 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618866677-275564 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, Apr 19, 2021 at 01:26:29PM -0400, Waiman Long wrote: > On 4/19/21 1:19 PM, Waiman Long wrote: > > On 4/19/21 1:13 PM, Johannes Weiner wrote: > > > The CONFIG_MEMCG_KMEM has become sort of useless now. It used to be > > > configurable, but now it just means CONFIG_MEMCG && !CONFIG_SLOB. And > > > even that doesn't make sense because while slob doesn't support slab > > > object tracking, we can still do all the other stuff we do under > > > KMEM. I have a patch in the works to remove the symbol and ifdefs. > > > > > > With that in mind, it's better to group the functions based on what > > > they do rather than based on CONFIG_MEMCG_KMEM. It's easier to just > > > remove another ifdef later than it is to reorder the functions. > > > > > OK, I will make the move then. Thanks for the explanation. Thanks! > BTW, have you ever thought of moving the cgroup-v1 specific functions out > into a separate memcontrol-v1.c file just like kernel/cgroup/cgroup-v1.c? > > I thought of that before, but memcontrol.c is a frequently changed file and > so a bit hard to do. I haven't looked too deeply at it so far, but I think it would make sense to try. There are indeed many of the entry paths from the MM code that are shared between cgroup1 and cgroup2, with smaller branches here and there to adjust behavior. Those would throw conflicts, but those we should probably keep in the main memcontrol.c for readability anyway. But there is also plenty of code that is exclusively about cgroup1, and which actually doesn't change much in a long time. Moving that elsewhere shouldn't create difficult conflicts - maybe a few line offset warnings or fuzz in the diff context of unrelated changes: - the soft limit tree and soft limit reclaim - the threshold and oom event notification stuff - the charge moving code - remaining v1 interface files, as well as their helper functions >From a quick scan, this adds up to ~2,500 lines of old code with no actual dependencies from the common code or from v2, and which could be moved out of the way without disrupting ongoing development much.