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 9DB3AC433EF for ; Fri, 18 Mar 2022 09:12:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DFDE68D0002; Fri, 18 Mar 2022 05:12:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DACC28D0001; Fri, 18 Mar 2022 05:12:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9B8C8D0002; Fri, 18 Mar 2022 05:12:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id B9F9F8D0001 for ; Fri, 18 Mar 2022 05:12:40 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 87EAC60C29 for ; Fri, 18 Mar 2022 09:12:40 +0000 (UTC) X-FDA: 79256941680.02.383A765 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf13.hostedemail.com (Postfix) with ESMTP id BF8C42001C for ; Fri, 18 Mar 2022 09:12:39 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 05720210EC; Fri, 18 Mar 2022 09:12:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1647594758; 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=Yk/mGHSn8BRwoxpYgM2QMot9CU5E0d7sStOUlUWO988=; b=HraKjKE4Fh3wvBHXqN+3Dkof0fl72OSnSPCpTwrGC2jGR9+4rlg/DhmiQWF0z4h7Qb6uQo 7GUHh7LFyhWnc8lMvZTS0RJQmDgkCyGn4JAke85v4kZ1BBzBUtuMgJIRBYMV51m7U8iw9W Hg5SwD8L7Z2hU8GqhH2KtFlpM0A6Y+8= 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 BD587A3B8A; Fri, 18 Mar 2022 09:12:37 +0000 (UTC) Date: Fri, 18 Mar 2022 10:12:37 +0100 From: Michal Hocko To: Matthew Wilcox Cc: Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC] memcg: Convert mc_target.page to mc_target.folio Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BF8C42001C X-Stat-Signature: t6i1336aijdtna4u6ma9mfi38fxij463 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HraKjKE4; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1647594759-759203 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 Fri 18-03-22 03:49:27, Matthew Wilcox wrote: > On Thu, Mar 17, 2022 at 12:58:46PM +0100, Michal Hocko wrote: > > On Wed 16-03-22 20:31:30, Matthew Wilcox wrote: > > > This is a fairly mechanical change to convert mc_target.page to > > > mc_target.folio. This is a prerequisite for converting > > > find_get_incore_page() to find_get_incore_folio(). But I'm not > > > convinced it's right, and I'm not convinced the existing code is > > > quite right either. > > > > > > In particular, the code in hunk @@ -6036,28 +6041,26 @@ needs > > > careful review. There are also assumptions in here that a memory > > > allocation is never larger than a PMD, which is true today, but I've > > > been asked about larger allocations. > > > > Could you be more specific about those usecases? Are they really > > interested in supporting larger pages for the memcg migration which is > > v1 only feature? Or you are interested merely to have the code more > > generic? > > Ah! I didn't realise memcg migration was a v1-only feature. I think > that makes all of the questions much less interesting. I've done some > more reading, and it seems like all of this is "best effort", so it > doesn't really matter if some folios get skipped. Yes. [...] > That makes sense. I think the case that's currently mishandled is a > THP in tmpfs which is misaligned when mapped to userspace. It's > skipped, even if the entire THP is mapped. But maybe that simply > doesn't matter. > > I suppose the question is: Do we care if mappings of files are not > migrated to the new memcg? I'm getting a sense that the answer is "no", > and if we actually ended up skipping all file mappings, it wouldn't > matter. Yes, I wouldn't lose sleep over that. You are not introducing a new regression. The feature is mostly deprecated (along with the whole v1) so we tend to prefer bug-to-bug compatibility rather than making the code more complex to solve a theoretical problem (or at least a problem that nobody is complaining about). Thanks! -- Michal Hocko SUSE Labs