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=-6.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 C076AC07E96 for ; Thu, 8 Jul 2021 07:28:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 55B7D61CE0 for ; Thu, 8 Jul 2021 07:28:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55B7D61CE0 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 237A86B0011; Thu, 8 Jul 2021 03:28:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E8106B005D; Thu, 8 Jul 2021 03:28:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B0DB6B006C; Thu, 8 Jul 2021 03:28:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id D73FA6B0011 for ; Thu, 8 Jul 2021 03:28:24 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2EC0B180301BE for ; Thu, 8 Jul 2021 07:28:24 +0000 (UTC) X-FDA: 78338592528.33.62824B8 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf19.hostedemail.com (Postfix) with ESMTP id 8E1A7B00018D for ; Thu, 8 Jul 2021 07:28:23 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4E0CD220D2; Thu, 8 Jul 2021 07:28:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1625729302; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=17LWgY1lhwnG10GPb9Rqj76fsBzvfjmM5lbcUo6gvVI=; b=Uw4AoXNSjnjAxhH0BbMXmIpo5cwyH7inw0BupZ8ZrmMINW5o3MMukZRtAyUTtg0uLnFh/x TFUwG0oFkek/lO57V9WITuUkWQfTIi4XJ4g9+sBzLLpC8JTMf31+0sAiWr1ik/nXg4i8g5 ZlDm3yNFJw+mbnmEXIbO3Z1LSUhdqIk= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 1E28EA3B84; Thu, 8 Jul 2021 07:28:22 +0000 (UTC) Date: Thu, 8 Jul 2021 09:28:21 +0200 From: Michal Hocko To: Matthew Wilcox Cc: linux-mm@kvack.org, cgroups@vger.kernel.org, Johannes Weiner , Vladimir Davydov Subject: Re: [PATCH v3 13/18] mm/memcg: Add folio_memcg_lock() and folio_memcg_unlock() Message-ID: References: <20210630040034.1155892-1-willy@infradead.org> <20210630040034.1155892-14-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Uw4AoXNS; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam02 X-Rspam-User: nil X-Rspamd-Queue-Id: 8E1A7B00018D X-Stat-Signature: 7rbnjz36qnwzpdjsai6rofpda6u3qkr1 X-HE-Tag: 1625729303-930665 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 Wed 07-07-21 16:10:49, Matthew Wilcox wrote: [...] > > I do not really want to be annoying here but I have to say that I like > > the conversion by previous patches much better than this wrapper > > approach as mentioned during the previous review already. If you have > > some reasons to stick with this approach for this particular case then > > make it explicit in the changelog. > > OK, I can point to the number of callers as a reason to keep the > wrappers in place. I intended to just do the conversion here, but > seeing the number of callers made me reconsider. OK, fair enough. My worry is that we will have this lingering for way too long. People simply tend to copy code... Anyway, please add a comment warning that the wrapper shouldn't be used in any new code at least. Thanks! -- Michal Hocko SUSE Labs