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 068E0C001DC for ; Thu, 27 Jul 2023 16:39:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BA346B0074; Thu, 27 Jul 2023 12:39:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 869D96B0075; Thu, 27 Jul 2023 12:39:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 709D96B0078; Thu, 27 Jul 2023 12:39:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 61E206B0074 for ; Thu, 27 Jul 2023 12:39:21 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2D1AA1610CC for ; Thu, 27 Jul 2023 16:39:21 +0000 (UTC) X-FDA: 81057952122.14.567D9DC Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf04.hostedemail.com (Postfix) with ESMTP id 348C54000B for ; Thu, 27 Jul 2023 16:39:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=AdhfcTm8; spf=pass (imf04.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690475959; h=from:from:sender: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:dkim-signature; bh=2yDMqgwJZJpeLWzTC3EjN9bRwWDIhFu5M1m3QL8b53s=; b=cXl1hCEgUV350aL4LDrRW1jluLp39EqvT+VrsqTOcejjwZlnKImmMbrBQroFPKDApZe5uX PdqZrSV6F9EzcRYJkLJsgm0+Na1CQmh80dAH6w8nlhMVuDAVGoU3Dw2yacxa7L5YCq4g/x KFgyhCnjyNbvZI+M5RvOc7nXI8rpGV8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690475959; a=rsa-sha256; cv=none; b=UNMocEm3ZYcS//KEcXX8+9wGtaXH9tNiVZnclHnnX5Npqmu6D33+Q1sCzzUKMnfECUWmyP rUZlPUPgjqzkL5AKSgPeXkc42FCxnGNoUNv8upy64uqaGQUZhFhDViAjrTWk3kubbrNWEK 0H2hYA0LPiuPgNNRAl2CjMpWG38gWRc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=AdhfcTm8; spf=pass (imf04.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4036bd4fff1so3711cf.0 for ; Thu, 27 Jul 2023 09:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690475958; x=1691080758; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2yDMqgwJZJpeLWzTC3EjN9bRwWDIhFu5M1m3QL8b53s=; b=AdhfcTm82K1GjFLigVcxGTETbwB4Hu0ZKLK+rVeYJhk06k5aXEomtq0SuD4my1yUGg G6a/EeSTlThiC82+Z4bb/j+2s0ml/xUhySNsXFOA6VBQOFGZDamFXY9HPFc97j6VTYG5 1e3d2EFDPlJjT/zTfCt+EjkDltdCVWOfiGhis7IWPppJdrn0DD5QVUmWhlKEzl+bjSib UYXeS7mDMrpUEzNQ3lX5EVaJgq/MZDpL+9hmU+DGwhEBLNQsOasCoVnXS4xZoegM3c2P U6gEU7zhObGvROVJgWVeMRLMV+9gxdLqC4/35IJiVicb67MCUB2Azg0hfZNEGGq3G8kR 5mXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690475958; x=1691080758; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2yDMqgwJZJpeLWzTC3EjN9bRwWDIhFu5M1m3QL8b53s=; b=VXAR+gvMbpt54hbCSb7tS6fTsT6aYTQLT3enqktUe3FteGIw8BdyQgkIR+4nhPjIdr i4leGMW5CKj/QyroBittN8b42rRuNY6DH+60McBpAvwSJWWQxMqL4ZCuQ869MfG75wSt 5r4zIfp6LIQuE0mS79UmMGaBLvMB2dp/IV/sfRHcTE44Y5ESipceSv/kVmy6M06QsSJv j8VmihvjAIkiuB2jv8mPzERnUyjx9lFvJre/JWxPiHa1HS/9FtEj1zz4sc0pwgW5VnxK KYM+CDmoBxRwu+qbX9Jd5elSs3Z+I25ky+L8F/ZdkVOxMLy3IxO4/cFnGDvfl8YgF3/t fEkw== X-Gm-Message-State: ABy/qLb0jE7u9IRYjCGm7cA+54z/RSMz+YXfZpT+vwSphRyzABzotdis QO1ba/o8nTMh3MpyRIGU8GWWValtRp8I+XQkSawiZg== X-Google-Smtp-Source: APBJJlFa6Zgjvg4Fw2GO4V4tr/e2Mu+mSsSifid6jwnpXQAx3UQnVcDy9mGobHKu9b2sKlUs8EavhIu7j8HTjvXvfKs= X-Received: by 2002:ac8:7d85:0:b0:3f9:a78f:c527 with SMTP id c5-20020ac87d85000000b003f9a78fc527mr207755qtd.21.1690475958109; Thu, 27 Jul 2023 09:39:18 -0700 (PDT) MIME-Version: 1.0 References: <20230720112955.643283-1-ryan.roberts@arm.com> <20230720112955.643283-3-ryan.roberts@arm.com> <87r0ouw39n.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: From: Yu Zhao Date: Thu, 27 Jul 2023 10:38:42 -0600 Message-ID: Subject: Re: [PATCH v3 2/3] mm: Implement folio_remove_rmap_range() To: Ryan Roberts Cc: Matthew Wilcox , "Huang, Ying" , Andrew Morton , Yin Fengwei , David Hildenbrand , Yang Shi , Zi Yan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 348C54000B X-Rspam-User: X-Stat-Signature: m49nmmoky3c63pqka84np1igapxj3uq6 X-Rspamd-Server: rspam03 X-HE-Tag: 1690475958-983614 X-HE-Meta: U2FsdGVkX196P0D1g3oQmWIn8dzewpH9+QL2OuHApXhAQQsnRb+PqiTQQmK6XBLAdQY7DhGQSuOOlyIglABj5bMens3dQ1Ad63Hr74/HLl2U554yTIisZVikr3RIwwNdBsK/Q7iu8lZpLj2ryiNWNQwyLHCPEiitv9pZ86FYh39PvHliAeFpDzq+m2/hyCvIU0KtWEuZw32+V+MhcVs1glN0MC20DoXLexUl208K1+6u4ltT6eivdpOrKwOSx/KrgwXdkXSSjSZYgoN5A7WrBC9aO6NdioZTbUk/3GAleCmOyCSHy3ztl+8swXZyAO2lnuy+5dy23q6cQTRxAS7Ja3TM2sslVnrhadAHu0RkVHZP3YXHM1zctcmFS/yZHH+oubtNPrtEnOMUqOlVq+cnf8w3UHDEk/E51gDMl6rYmRikZUlngtP3gzpp5QYq6zO82ueFpN+FRgU2vJsoWhcWL2YnemGUgS59RkWL9dtv+v8HZ+qGZEV843J6IxPSKcMtSocOl8ERcqoL/l49slqCmFxRDY+g0ha7WOpUlQj4oaPT3zMwwVQR7pvbGwcFmqi4149OcDCXJGiTUNi+fRqUjOJo4UBz6V2UW1cJqGuPsO20GeXUtEYtvpyw3wHzxoWPNF+M5X9+SxdvK6MAjZXzLA6aSJv+l1KBy87rMrX7xhAZlr7psEaITjDj6OT3CsM9Wj/vTdDGRkqM4FzG6h6AUaGe2ABcIi5Xk4OvGczDkiBnoNVdSwS2LQEpDj8SA6ZshWjKQjEu1nBW1kK9LrcYV/l5IliSAZ/Ix/gEosj1oAzWnfsmqUHWvzJB5rR2WRnO/BcfAUkHhhu3qk8uBg6weqskRb7V5FsWvJedWHjJancx1/VpryiU9guz91LOmNGUtaYtuxDZxZ99ygtStUGf4OkAJNLieJarGxsNDyeQSK3Sao/8ylhulN1eI+AwAJkiSGqkwYfwymP7I/R1bf/ f7K0pbyj d2gaCoXkXtDgxk8siyt3dzvqLvse9cZk/01ElC0ic+Kc0iM+ol3BdAnk0Vmla/8+H5Q7nWdFo40fAvranIvnxU4v8Hke4kJg0YBBDV4qz3Y5Wp4QangF7c8PfjwQmtTvzeB4XldD0N6K37aPjLVLRImrTRxBsjK9ZZUz1A16UmgeSqUkqgSyLhyBuvXrzQWuF6ERa1sntEabJ30jUb5MPuvjnAcbHJwAsaWl8e6+9Vy6p6O3OGAEX4aA0DimNAbag1rzirQaNGq8X+K/5XRjEFat+vo9wAIDl1X7QOdgKfuUjEgNAx+zqYNoKIW1XeSAKj3vdXUNpHY4SM0KrhgFmdJZZWGRRAPVg/6ODz6ucCSiF7YgSCLyv/73kQ9jyCrSPL4z9GYiDidgtR4Q= 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 Thu, Jul 27, 2023 at 1:26=E2=80=AFAM Ryan Roberts = wrote: > > On 27/07/2023 03:35, Matthew Wilcox wrote: > > On Thu, Jul 27, 2023 at 09:29:24AM +0800, Huang, Ying wrote: > >> Matthew Wilcox writes: > >>> I think that can make sense. Because we limit to a single page table= , > >>> specifying 'nr =3D 1 << PMD_ORDER' is the same as 'compound =3D true'= . > >>> Just make it folio, page, nr, vma. I'd actually prefer it as (vma, > >>> folio, page, nr), but that isn't the convention we've had in rmap up > >>> until now. > >> > >> IIUC, even if 'nr =3D 1 << PMD_ORDER', we may remove one PMD 'compound= ' > >> mapping, or 'nr' PTE mapping. So, we will still need 'compound' (or > >> some better name) as parameter. > > > > Oh, this is removing ... so you're concerned with the case where we've > > split the PMD into PTEs, but all the PTEs are still present in a single > > page table? OK, I don't have a good answer to that. Maybe that torped= oes > > the whole idea; I'll think about it. > > This is exactly why I think the approach I've already taken is the correc= t one; > a 'range' makes no sense when you are dealing with 'compound' pages becau= se you > are accounting the entire folio. So surely its better to reflect that by = only > accounting small pages in the range version of the API. If the argument is the compound case is a separate one, then why not a separate API for it? I don't really care about whether we think 'range' makes sense for 'compound' or not. What I'm saying is: 1. if they are considered one general case, then one API with the compound parameter. 2. if they are considered two specific cases, there should be two APIs. This common design pattern is cleaner IMO. Right now we have an overlap (redundancy) -- people would have to do two code searches: one for page_remove_rmap() and the other for folio_remove_rmap_range(nr=3D1), and this IMO is a bad design pattern.