From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f51.google.com (mail-yx1-f51.google.com [74.125.224.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D1FAE2417D9 for ; Fri, 13 Feb 2026 09:03:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.224.51 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770973383; cv=pass; b=qVlSnd7lrZSLn7nfNsmv+1vPKqc5uhOlCSTwPo1AKTUWe0W+3APXEx4Xk0sjVgUU0lXK/dxnhyudrU5B2EfCpAy8p8s1pkQ/i1t31mx8/ytOGPILDY3PuyaAkgD+gI/Me632ArRcl7DArHNJ9Htqv+XD+wZwUH9LEJRWEbbx0yc= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770973383; c=relaxed/simple; bh=szpmv4yzFWjp/zVTqwAiFCmEOO4/UbzpYWHHip3BGkw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=XkCuLTYOz6+dBLj8dPLxw/dEGWaQTbNcg0grCaVDbKR7aBzDaxfli9tI/1Z2is9328hbVWHrEj6NQM6oqgn55wk6YQH8gS7YUA+6gc68YZeBWTcj2V69DZP/jgBx7e//44KBddhxA/K4nXiCc7vl7azk+9aB8cBm6AdE8IL3g1g= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SduW1Lb+; arc=pass smtp.client-ip=74.125.224.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SduW1Lb+" Received: by mail-yx1-f51.google.com with SMTP id 956f58d0204a3-64937edbc9eso612872d50.2 for ; Fri, 13 Feb 2026 01:03:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770973381; cv=none; d=google.com; s=arc-20240605; b=GmjPfkj+9I4RujF3VBY4eK+Hfn2ZEjXVweMgWdRLAMPHCJnkqs5wxk0oeXs1HRyYOZ fHDKo+7FHIHfai+Ad2SQr+7Tx7hfGvQ1DbA75mr8uaU32YZXztP51v+8bPYAA9k9TGDN GRqO59yB7gdwcujmAjfqf6dflK5QhVdICrNSsHSj7EjpahHDVZUV9UHx/IqW3KRpEnpb mygRt57kFXuta6AVPEoOwHGR9sHzDAXFso2nimhVjazM6KLBIpiwWMoad+J8uqA6Ch+0 8bW9BG8jD6jWy0bU6Tp/s4Rsahyh3masQW6eC8NUR9R+iWnRbF/qIOUMfY1rAcLbFIPZ ebrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=aKBMPANl0zC8AGiCOQJvZ+fUUtPvF2idCFAEvWrwChs=; fh=6QalvuEbPI8E2Z/a3o/u/iO0dtq8CyiCX51TnbKO8FQ=; b=CQ/3L/kiAZrDd/Xmakfp0PM1c8I04hGmOEWm0W28Gfon/mIvWJV5YUgtKdz1qjDYDw irEfCzj1oF/Ya1jzXSZCA3pEvvh+PmdDg9MJsHl2jB07u7qcDtPQEI8cYQA3j0lrlnO2 xRP8rjC1frWH/OhqkfR8KRBjzCFOcLXvsM1ous++peVB4jEc6e38UY8I3l+lXU/WcnIn GekICuTp/dCDbdZdZNY0/9Lb27+WwmXVk8ircZK44WoONxTJojbuITNxwzWfmABjhoNV YgcG31dTKfqOr/oEfFMfSvmhRErxfmPY4IhY2J3IZ0MYRhYMGF7mc+7u0Zs5nkvYL6es fCew==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770973381; x=1771578181; darn=vger.kernel.org; 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=aKBMPANl0zC8AGiCOQJvZ+fUUtPvF2idCFAEvWrwChs=; b=SduW1Lb+ivfqZ1S9VGt1NEW5M1my1usb6Nzywl89mqNVXoUxbfFeL0VON1mtTRvvH+ JiYYUTeRbvDijRKCimMzx+KFIVnYltmOn7k3A4ybhB2HB3AhlSYb51jDf9SIp4HhFZj+ ykbsQTQnpjXFptWpWCAPnhGAKFawEtuFVdUdTojvHdWAil3F9riR8eKhowYQrN3XjwhA 4PMfFPTYQ01eAMhYFu8wH42knWd/T5pv0uo7zRt+vwvzm3Fv8Z47aGn6XD2yj3WIwaZ/ 754bJdeCaQU9VO1xvkT5EOkXp1o35XLbC8FFinp29fMS4L1agcGgLT7nKXsF3/diDcih G2Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770973381; x=1771578181; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=aKBMPANl0zC8AGiCOQJvZ+fUUtPvF2idCFAEvWrwChs=; b=HnKkUa1BjjpQ2zYVZzKObMZMOfsffSH/aFv4dO4wuUEX+RBnhmkb9g2qA4NvzqC+vu ebwMh6BEECglKlBT+ad5W8IA6nMrc4CY6HrsDMxvUM3JsnBtMR2dUJqjctTdPP11R4u9 mwaFumb/GD2936XePU5W3n7Gg8bkeLYmrUSTzITb6rEZgkP+/Yp20xMu1Enzwatcws0d bAuYOca2WCwIn04t7wqUf94SF89VFX9mkZbkIGqfYGotdKZHAGkV36zg+jfSCgiCfo3H JVo/TPMYXQxNyLTC09sKZ3+DOfenf63JuK8pZiK4h5lzXUQfRGtN5NPBnE/kbZ6PyQfK dJ8w== X-Forwarded-Encrypted: i=1; AJvYcCWXqnxqjqj/F8tBVrqTr5tBs6IixUYSXxPZ1k2WO9VUU5665w+fJMqFLC4MzrtA3GM6CgyAiFdb93pAaIY=@vger.kernel.org X-Gm-Message-State: AOJu0YxGveWarKEqr4a2lmVqwospoeFZOHYwmJHAe9/lf9omW2DH0X4A ljdPwnTnXjTEjXr/YkxzLqbhtqlLDRVBAgB7Ugswq48VKdn/b5jb1pieak2hgNJZjpxu5o73W7f +mMnp1+hUT5lvM4dMA3NNAr8XnctgXvI= X-Gm-Gg: AZuq6aIfFdxvdtiqvtIyfhnPzh9NbnEBXEx9XZkZbJUSGmj0Q2zZ2iQzEkwrSqLtnIu 8/YK673vUpom0vmWXSEmf31p7+J5OTu2uVnOn1JYdW/quA1ZzCw3IrcipSUXkwD7+tv/rsUB3P7 ooOc3+nwO2/Jn+RdxY/uHgn7Ma6usah6cAwk7dgDhb9jc0indHJNBzcqkmvq9oV+MrdwuI9DMJP DHaVaaHu5Gj3yXL26uZZ0NYK+m5g1POC+bZt5sYhI8us1WNMQEqqlBMFkl004ijiPIKt9zVlZpe GhtxIBF+ X-Received: by 2002:a05:690e:d48:b0:64a:f0cd:d41 with SMTP id 956f58d0204a3-64c19b7dd38mr544534d50.87.1770973380743; Fri, 13 Feb 2026 01:03:00 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260210043456.2137482-1-haowenchao22@gmail.com> <5c4d773c-e3e7-4a71-b250-91701cbdd4a2@kernel.org> <201fcbb4-c43c-406c-ad54-f2c9301c12b0@kernel.org> In-Reply-To: From: Wenchao Hao Date: Fri, 13 Feb 2026 17:02:49 +0800 X-Gm-Features: AZwV_QjmPqmh9315TuUo2mAOGUPeyMxgesQgByTwQp9e01nHNjs-eVDlLfycsp0 Message-ID: Subject: Re: [RFC PATCH] mm: only set fault addrsss' access bit in do_anonymous_page To: "David Hildenbrand (Arm)" Cc: Andrew Morton , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2026 at 4:54=E2=80=AFPM David Hildenbrand (Arm) wrote: > > On 2/12/26 02:57, Wenchao Hao wrote: > > On Wed, Feb 11, 2026 at 5:05=E2=80=AFPM David Hildenbrand (Arm) > > wrote: > >> > >> On 2/11/26 01:49, Wenchao Hao wrote: > >>> On Tue, Feb 10, 2026 at 5:07=E2=80=AFPM David Hildenbrand (Arm) > >>> wrote: > >>> > >>> We have enabled 64KB large folios on Android devices, which may intro= duce > >>> some memory waste. I want to figure out the proportion of memory wast= e > >>> caused by large folios. Reading the "Referenced" field from /proc/pid= /smaps > >>> is a relatively low-cost method. > >> > >> Right. And that imprecision is to be expected when you opt-in into > >> something that manages memory in other granularity and only has a sing= le > >> a/d bit: a large folio. > >> > >> Sure, individual PTEs *might* have independent a/d bits, but the > >> underlying thing (folio) has only a single one. And optimizations that > >> build on top (pte coalescing) reuse that principle that having a singl= e > >> logical a/d bit is fine. > >> > >>> > >>> Additionally, considering future hot/cold page identification, we aim= to > >>> detect 64KB large folios where some pages are actually unaccessed and= split > >>> them into normal pages to avoid memory waste. > >>> > >>> However, the current large folio implementation sets the access bit f= or all > >>> page table entries (PTEs) of the large folio in the do_anonymous_page > >>> function, making it hard to distinguish whether pre-allocated pages w= ere > >>> truly accessed. > >> > >> The deferred shrinker uses a much simpler mechanism: if the page conte= nt > >> is zero, likely it was over-allocated and never used later. > >> > >> It's not completely lightweight (scan pages for 0 content), but is > >> reliable, independent of the mapping type (PMD, cont-pte, whatever) an= d > >> independent of any access/dirty bits, leaving performance unharmed. > >> > >> When you say "I want to figure out the proportion of memory waste", ar= e > >> we talking about a debug feature? > >> > > > > Thanks for your explanation. I now understand the design logic. > > > > What I=E2=80=99m proposing is mainly for debugging. After enabling 64K = large folio > > on Android, we observed increased application memory footprint, especia= lly > > for anonymous pages. > > > > Since Android app memory usage depends on runtime scenarios, we cannot > > confirm if the growth is directly caused by large folio. We want to > > analyze memory > > usage via the `Referenced` field in `/proc/[pid]/smaps`. > > Scanning for zero-filled pages will be much easier and more reliable. > For a debug feature good enough. > > I'm wondering what the best interface for something like that could be: > we don't want to make "/proc/[pid]/smaps" slower for all users. > > Maybe we could for debug kernels. > > For example, adding with CONFIG_DEBUG_KERNEL a new entry > > Anon_Zero: > > counter that just tests whether the page content of an anonymous page is > all zeroes could be doable. > Apologies for the delayed reply =E2=80=93 I was just writing a demo to veri= fy the approach you mentioned. Using the CONFIG_DEBUG_KERNEL compile-time macro to isolate this feature is indeed an excellent idea. However, in engineering practice, it requires recompiling and replacing the kernel, which can be cumbersome. Could we instead use a dynamic switch to control whether scan for zero-filled pages when reading /proc/[pid]/smaps? > -- > Cheers, > > David