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 1F519C6FA8E for ; Sun, 5 Mar 2023 10:24:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69D936B0071; Sun, 5 Mar 2023 05:24:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 64DA96B0073; Sun, 5 Mar 2023 05:24:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 516666B0074; Sun, 5 Mar 2023 05:24:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 41D566B0071 for ; Sun, 5 Mar 2023 05:24:45 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 10045809E4 for ; Sun, 5 Mar 2023 10:24:45 +0000 (UTC) X-FDA: 80534460930.17.70D218C Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf07.hostedemail.com (Postfix) with ESMTP id 4523640007 for ; Sun, 5 Mar 2023 10:24:43 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NHHME9OY; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678011883; 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=cqMINr6iQSeskbEpBS6bkpmue99yioMBFhLHh7sxvHs=; b=6owOp0WJKUuaJJcedC6gCPLOZBk2hxGds4j1KPNTDGtblb6AgpwgNkVwTg9rCFAzS93klb ij9V/n4FRwzRKm511qpnQ18lCYNf6WV8orGTrpq2Ubx/8XiI+CgmFzjUcNMhvj0uKEax8v HssfsBnuNh8iCmKmizCIZKIbKHDaGXg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NHHME9OY; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678011883; a=rsa-sha256; cv=none; b=vLth3rEJ7uSqUaCuPaXTrORB2IQ3wsTnProTzAuVGbISI0TYGfTs9JO9H1JEj2yPvohop6 XCtyFswDOI6vR+uhDlXOUAy3BNN/s/srJRn33lVeOTpuQTAmk6aLzT6upWxVb5I74V/ECD pI6onVZvZslrpBgpGhC4IPABaMFcv9s= Received: by mail-qt1-f182.google.com with SMTP id h19so7618496qtk.7 for ; Sun, 05 Mar 2023 02:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678011882; 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=cqMINr6iQSeskbEpBS6bkpmue99yioMBFhLHh7sxvHs=; b=NHHME9OYNe5qcDM7ezj/qgLYaateTVLfjHc0wFx7pHAn58Ixrtyw4RJ3pfnWlhov6P +4L082borw06qmOc9/qfCNhmQORt1+phuwHStY3VxL9ECAE5zIkX2LI/nipPYActtZFC ZW9sThVZJ0MdHpR5EPqxqQPY7KkW+u5tThtSeZoteiahhRRIkVywiGeNwOYMQoeLozn3 dyDf56mqCDxPG9dS7J0tk++jeYaYL6jO0e19e4EIZlUC467VsPFwZqlFcqB+RoqSQWD3 9EvTVENGSqeis7wTglZSA38fA3EihOwVgDoYrCYvybakxOqIUmi+Kf0dG9aR+oQEL29l bW2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678011882; 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=cqMINr6iQSeskbEpBS6bkpmue99yioMBFhLHh7sxvHs=; b=GD3GjnyOWRL7LFmlWUNofCsJKuxW6PO7m6tsywGhld9z07CWd3/E6vbtlswdR9I0if Ff6OIimAQd3dWLJvvJtH7NpYCgaeElclES1L2geNaBNOp9WaYn03JBM1Io1ibjcwm46X 2WTmkw/sEi+oa1WryfJ6IWKVNakPpg3inlItI1NjbdIeuRqevUKay8jhKyKO3ZpQuew0 f/TLkdqmN5R1GuAMETq13BwEV2nq74GYEigpiA6snP5nGWlLGPkg3V7toqznU7NidJZN zvzUCiWNoOlfEzMPn5CTJOFQjJrQ5iPSEnNN+EXkm1LBzVRER+whGiRD+wKG8SBwAYa1 4FbQ== X-Gm-Message-State: AO0yUKVwNAZX75ZaosO7HEq6LIkVGC04teYPh1kk7nd43DmtAjk7efx6 BivqzqewQgmQuUSVhjO3W/OBI77sTHLYJKFfGK4c94H5mWO0AA== X-Google-Smtp-Source: AK7set+dBxXSlIEGi6EDukdzbUkI+kB8AePqzhPv7tgQhbrKr02somGK3IPoQy8PAOjVOz8rniLhFAoZuKRl1uB7VKg= X-Received: by 2002:ac8:56f6:0:b0:3bf:d993:f353 with SMTP id 22-20020ac856f6000000b003bfd993f353mr2249036qtu.7.1678011882326; Sun, 05 Mar 2023 02:24:42 -0800 (PST) MIME-Version: 1.0 References: <20230219073318.366189-1-nphamcs@gmail.com> <20230219073318.366189-3-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Sun, 5 Mar 2023 02:24:31 -0800 Message-ID: Subject: Re: [PATCH v10 2/3] cachestat: implement cachestat syscall To: Matthew Wilcox Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, bfoster@redhat.com, arnd@arndb.de, linux-api@vger.kernel.org, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4523640007 X-Stat-Signature: 57u78oz6nrkwetn98t6syeoyjkgsq9q4 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678011883-453573 X-HE-Meta: U2FsdGVkX1/bGUgvkT0v+zuQgFbtwg5ZkLhZMxKtzH7rNvIWbjYJiC8RcDxGNXgkVr0sgAOc/T7/q8WooHmExNNhESYqIgvipI+QTa6lnvQjnk4fGKeeWzWN0Imhc++mKNMCmYgYTA0zdPjVedbDiyDm7872kd8kSpHWx/Q2T6/RL8yXNdi8CM+vhv5sQwD4L4XJwaGAHMCTCgg2LBCymZUdgMIe2JTNTpmCsClDCPPtRpq36GlACxW+56oyed8/J3ZXqI2qCJwQ/9RqlD1BZ3S8sRbn/A/VatoCGPyiqITwGOwdmrDVj+8YCRiSpriZbt5TNTfcw+pkGuURwdFAmRAGDw1FR5x3YX0wL+5RV/swV0/WMGl/dDixSowxsbfyNdZR3mn2pj2ay5qUnww8e6rP6Zzg3faumSX+J+I6QK0TwIlah2636qoh5vbuleV//oTWY517I0S7vkZFj6I7UOt9k18zE+Ab0nd0hrhcjOxK4RVMrMUHA4eeuM8P3Q0/nE7YSvVLtMrXUYwzRUDqKjbiinqPwtWOW1mxV3vNrqpMdirv1MNWnE6eAbBDixqMu85c9VkB/bB/RkROihYcQa0ix+nlVIeDTYE2Wio3TLOAjA2YR1ARtLW9CijA23+hKxdKoLbRejVgKVFslTk+8o+QMLFYqUWZlKpnEp5O2t6+m6Zyh5w9Oyw5a9YLOuuS6+ih5RBKM8SthQAn57DInufAn36edaCMyPq44R56ihM22HxCtOa9gO4x7FX2g9T9un/qYnzCG6UmeH4LaMtCwBmIF6kidyoQPA39d8dcUh366US6zNLpDpRuwUtVWOJycf2a+Pm3sNpyOmOd38N5UcUFbURqgpE4r4Y/nlt73vFvy8KqGTuFZJYCKTbHT7/xB223M87rsLGoWPKeu24+GFkw0XMQOWlL1e7O6NlQ0BjFL2iV7gybydMy7H3fh6R3vhdxCC1EMbwDOJOjhxo 5GiA8YG9 iviw846xv3utc7sgYjO2Ypkf5CNlktZbtOp6InCK3HSDuTfI9Dur67NuI5qBgmvvrCQYqzux0d3fzvTxuRk5NL4efug5dtgAaum/c3UCDZ4ajaX7zYfA1T7l/m++3vYwbasA1pJBUzATwkdu1zBnBacHoYkdmc0pyc+9fkbvPQsITYe1bjPiS8Ueb3wqlDDl5J3BEQ2EZFZ+uvFIVYJtLOOllOVCIOJsDD0jBr4V+0f3NMpKnYdpKLT5fKhDl/q81EyvFVsvXCKopvvyhoDDeOvG4y4u0EQscdGikaHZfluABwYVJJO33SbVG9BVu5NS5GGJs9oBPHFk8oOk1H7Gg/gFZMolX7KJSCXwfGZ6iEITTBcQ3+ilNCw3yvt9kyC9OQr1oBlT/6hVdnVLP71oEm1MtmGVnXvi7JelSDzCAQoIqSzsZ1mIUhwpO9A== 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, Mar 2, 2023 at 11:03=E2=80=AFPM Matthew Wilcox wrote: > > On Thu, Mar 02, 2023 at 10:55:48PM -0800, Nhat Pham wrote: > > On Sun, Feb 19, 2023 at 4:21=E2=80=AFAM Matthew Wilcox wrote: > > > > +/** > > > > + * filemap_cachestat() - compute the page cache statistics of a ma= pping > > > > + * @mapping: The mapping to compute the statistics for. > > > > + * @first_index: The starting page cache index. > > > > + * @last_index: The final page index (inclusive). > > > > + * @cs: the cachestat struct to write the result to. > > > > + * > > > > + * This will query the page cache statistics of a mapping in the > > > > + * page range of [first_index, last_index] (inclusive). The statis= tics > > > > + * queried include: number of dirty pages, number of pages marked = for > > > > + * writeback, and the number of (recently) evicted pages. > > > > + */ > > > > > > Do we care that this isn't going to work for hugetlbfs? > > > > I ran a quick test using hugetlbfs. It looks like the current > > implementation is treating it in accordance to the multi-page > > folio case we discussed earlier, i.e: > > > > - Returned number of "pages" is in terms of the number of > > base/small pages (i.e 512 dirty pages instead of 1 dirty > > huge page etc.) > > - If we touch one byte in the huge page, it would report the > > entire huge page as dirty, but again in terms of the underlying > > pages. > > > > Is this what you have in mind, or is there another edge > > case that I'm missing...? > > Hugetlbfs indexes its pages by hugepage number rather than by smallpage > number. Imagine you have a 2MB folio at offset 4MB into the file. > Filesystems other than hugetlbfs store it at indices 1024-1535. > hugetlbfs stores it at index 2. > > So your report probably seems to work, but if you ask it about a > range, you might be surprised by how wide that range will cover for > hugetlbfs. > > I know Sidhartha is working on fixing that, but I'm not sure if what he > has is working yet. Oh I see! Thanks for letting us know about this, Matthew. In that case, I think we should just drop support for hugetlbfs for now. It's also an odd ball - not swappable, no backing files, not fully under user management, etc., so it's less interesting with respect to cachestat as well. In the future, we can always lift this restriction with a follow-up patch or with Sidhartha's fix.