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 79C6FC433EF for ; Thu, 17 Mar 2022 11:58:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABC7D8D0001; Thu, 17 Mar 2022 07:58:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6B686B0072; Thu, 17 Mar 2022 07:58:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9331A8D0001; Thu, 17 Mar 2022 07:58:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 8204B6B0071 for ; Thu, 17 Mar 2022 07:58:52 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 6385E61259 for ; Thu, 17 Mar 2022 11:58:52 +0000 (UTC) X-FDA: 79253731704.06.CF095E6 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf20.hostedemail.com (Postfix) with ESMTP id 9C17B1C0020 for ; Thu, 17 Mar 2022 11:58:51 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 31AA91F38D; Thu, 17 Mar 2022 11:58:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1647518330; 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=wChL9XS63MYTCqGru1PZgU6kXfV3LAvy/qvsXt5I990=; b=h3+TM1ZrSfGxCkXKnqPsDUbK+eHEVAXknuif+p/x7hAdQHZFNK1NeAZO4y21h3OblEiA9R OqYeRMTMbn+OoLUt2baZDoi4ptha3Yma20C64NsqA0ksLVxffDpaNs1UsQwQNeOMV1jFk+ q05bG4BaY7leR0xAACBdJcsddQyxbMk= 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 E3879A3BBE; Thu, 17 Mar 2022 11:58:49 +0000 (UTC) Date: Thu, 17 Mar 2022 12:58:46 +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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9C17B1C0020 X-Stat-Signature: 5ccnxyt33egi7eyu5745z7zzdno3zsgm Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=h3+TM1Zr; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-HE-Tag: 1647518331-303795 X-Bogosity: Ham, tests=bogofilter, spamicity=0.002131, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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? [...] > @@ -6036,28 +6041,26 @@ static int mem_cgroup_move_charge_pte_range(pmd_t *pmd, > case MC_TARGET_DEVICE: > device = true; > fallthrough; > - case MC_TARGET_PAGE: > - page = target.page; > + case MC_TARGET_FOLIO: > + folio = target.folio; > /* > - * We can have a part of the split pmd here. Moving it > - * can be done but it would be too convoluted so simply > - * ignore such a partial THP and keep it in original > - * memcg. There should be somebody mapping the head. > + * Is bailing out here with a large folio still the > + * right thing to do? Unclear. > */ > - if (PageTransCompound(page)) > + if (folio_test_large(folio)) > goto put; > - if (!device && isolate_lru_page(page)) > + if (!device && folio_isolate_lru(folio)) > goto put; > - if (!mem_cgroup_move_account(page, false, > + if (!mem_cgroup_move_account(folio, false, > mc.from, mc.to)) { > mc.precharge--; > /* we uncharge from mc.from later. */ > mc.moved_charge++; > } > if (!device) > - putback_lru_page(page); > -put: /* get_mctgt_type() gets the page */ > - put_page(page); > + folio_putback_lru(folio); > +put: /* get_mctgt_type() gets the folio */ > + folio_put(folio); > break; > case MC_TARGET_SWAP: > ent = target.ent; It's been some time since I've looked at this particular code but my recollection and current understanding is that we are skipping over pte mapped huge pages for simplicity so that we do not have to recharge all other ptes from the same huge page. What kind of concern do you see there? -- Michal Hocko SUSE Labs