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 B8622C021BB for ; Tue, 25 Feb 2025 16:36:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 353F428000A; Tue, 25 Feb 2025 11:36:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 30443280008; Tue, 25 Feb 2025 11:36:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A55E28000A; Tue, 25 Feb 2025 11:36:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B487D280008 for ; Tue, 25 Feb 2025 11:36:25 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D594A1C80B6 for ; Tue, 25 Feb 2025 16:36:24 +0000 (UTC) X-FDA: 83159019888.16.4776947 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf07.hostedemail.com (Postfix) with ESMTP id A0BFF40005 for ; Tue, 25 Feb 2025 16:36:21 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ki2w8xfi; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=9Qe53lea; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=MTRufa88; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=E5rvB8Yz; spf=pass (imf07.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740501382; 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=PiCce6OsxqzWvruanZPQSkDrsXsjyuoHKjj8amNVC6I=; b=srTqBdNfKh99mfd82QT5Ib19VN8asfyo5atU6940zp4c1RJxO5eHMQY+oQHV+fFv70shRA dki9Xu5cA7VMRZ6sM4ShmhxKp6FOZGCe7JDuiHGWPDUUjkAI7GarnEmyoaYoD8155zZzcu 2GqivSuPreNJnTGh7JjJZ+qjiYd1Cjc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ki2w8xfi; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=9Qe53lea; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=MTRufa88; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=E5rvB8Yz; spf=pass (imf07.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740501382; a=rsa-sha256; cv=none; b=QiUbq2EjaFkogE3OXE3b7a/O/NycgzSboaYG9544pdsXTy8zRQJF2HwVbGEdI8+IICwO9j HrDhMlgrHGzNpuZi5xuS5/j/VXUWeZWNP9UPhWhC5MaQGD64fFpQdu6rqdgxcPUMScHYGV O2R4AUtXGyR0KwkXb3UzoJai0UuuZl4= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id D3A271F44F; Tue, 25 Feb 2025 16:36:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740501380; h=from:from:reply-to: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; bh=PiCce6OsxqzWvruanZPQSkDrsXsjyuoHKjj8amNVC6I=; b=ki2w8xfioEAPzRw98WhKB7xOFgR1laC6zeJvJc82rRof4UpXmsOymvww2qeaEgSUqTHD09 RS9vnxf8dErrmqtKdRJqby3xVsibJznmSj/oKthL/vzvhQ9y7dsLmJ6VgW/uLgljBgMn9b qZGbgRhiLeD+7WIf/0u8KGRNru25i9I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740501380; h=from:from:reply-to: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; bh=PiCce6OsxqzWvruanZPQSkDrsXsjyuoHKjj8amNVC6I=; b=9Qe53leawz8dSpjTbDinKf4tZ0xFQKPuutjCzbgbMJ4PrX6b31ii5OPGy1DSGWbWuXCetU D9eoI0rSsnf2uDCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740501379; h=from:from:reply-to: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; bh=PiCce6OsxqzWvruanZPQSkDrsXsjyuoHKjj8amNVC6I=; b=MTRufa88Sg73b61LE7l3CPDpLXxbpqI3rO/o+2Dy7bVschXKaBd9seBkaD5CIMJnNfcc03 R7w1hMW0KYLC3LnnzYjKRoaaavzZhyPgK4aP9NSugiFPEXXxChb5h7QGnagw5TVCCTDrSw fYSnuFdS9zMu8XVKzmHGhcUituHj+wY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740501379; h=from:from:reply-to: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; bh=PiCce6OsxqzWvruanZPQSkDrsXsjyuoHKjj8amNVC6I=; b=E5rvB8Yz7OmgX28mcmHB0ftybK9BCxiLTzlMyCdnnmMSpFGMXBQCv+TxAOS/2f0iw+Bx24 3kbZe95cVJ/p1lBA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C834013888; Tue, 25 Feb 2025 16:36:19 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id HbfZMIPxvWfLQAAAD6G6ig (envelope-from ); Tue, 25 Feb 2025 16:36:19 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 82F7AA08E0; Tue, 25 Feb 2025 17:36:19 +0100 (CET) Date: Tue, 25 Feb 2025 17:36:19 +0100 From: Jan Kara To: Kalesh Singh Cc: Lorenzo Stoakes , Jan Kara , lsf-pc@lists.linux-foundation.org, "open list:MEMORY MANAGEMENT" , linux-fsdevel , Suren Baghdasaryan , David Hildenbrand , "Liam R. Howlett" , Juan Yescas , android-mm , Matthew Wilcox , Vlastimil Babka , Michal Hocko , "Cc: Android Kernel" Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Optimizing Page Cache Readahead Behavior Message-ID: References: <3bd275ed-7951-4a55-9331-560981770d30@lucifer.local> <82fbe53b-98c4-4e55-9eeb-5a013596c4c6@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A0BFF40005 X-Stat-Signature: xah6niyfajbek8k9qojgh7wj161dtexw X-HE-Tag: 1740501381-663216 X-HE-Meta: U2FsdGVkX19UVXtOVam2SbBznvRHBTxAw2IVqyRlD6m0U6ve+iKhw8Y+9p7oT5EkQ6LeAZ7DETI3qfVq5+EjQYKKK5zQgcE+CkmTTgpq0sN3woTyMN+vHWTiZyg7OcNUSU6TOJu9ik/8EErbI44ElxUOPgeiBQlIgTf4PfRtcTq6yla2Yx3P+Y4TR8RNnika0w8V53g/lYBQ4qh4W8wgtBdDZDLBRRhjxsRPRfJYR2sDhmOG41yXfX+8tSq/zE+Rt6FL5U/h5IrcGFpPo4UiJSommXTCWZJgadiK7Eg0LbFQOYCp9Q5cLdbw0QoZUjFNm5lLYhv7h9d3TZAxo8uIhkZLkOuDMajtMgV5Wt7RQwzIW5bKE0L75qEcwYx5fqNXWFLdHUzwAbkCClB11EGGZclNVMtXXtGTCY6dMjTj14gJPQH2K9+q+NSY14+/DzZ9zdYGybilnlc28lPq3YaIzLT7rCDk4CjgPZNyftYVJqw00X//5AfYZg/QGm4mKWO5cHs04q3ZxHoUsxkiPkYvJ+WUTxNc8V/RIxjeTf+IfA1e1hrk4nUHejn0UnzRfVdd7x37iBXw6kaH6JjdTRNQNCSNLEvGpz8D9lJDiOpAild0JxjXc7eVXCr29mBQxnQE39SB/+xFU4FroETBH4bzzd09lLJLt8fWbzzs7RVbNoUkOiWdCTUOKtjvaTyGiTqU1xiyvvRRKVFgHEGRN9yUX1PhthohILyqhp5XOx14AZ2VwwvygsNDlVPJGfb87RqZkJZXASzmZWG9Uf7FVTko62YF0jl2+WT1Q90fpue6rNdf21O1yaPbpu4pVrAObej9mfacsNITnS/ylDCx6NNkf4jSV9EsrGHJFfnOQdomD4cVWjbWB95zq2OaTXcsoYPdNKPf/CTkCvSvpKgQqR/tQAdyA9HPPCzMRbuNeCWzaOljrt9hpWfvFVpBP877TSclspe3+5I1Huj6JbCjfOZ sjdahj+a maF/zmmIrm/cqZP+QdfZJyf3nepiHllXnKN8fgZD7x+7isn4k1ddk70H+tzUQg3JUGSlfiRRy3m0cHgbPbfzPWssHOtx5Hcn1i+SJykMVRmwr5psGffN1uuZiwJqZtUQf6uZZzjXT6jO/jwKPKcuA2i+hL94ZF2SwOfiDfYvJRCiukORWlgJF+EYgP6HP9a8B+mbnWLKXGDWeBEN+DTc0AXSOisz7GgyCDqgirkA6bAhpq2XKQ26SzsGE85fn5MnF1jaE7A9r0zwu58GcigC9WBT8XgiVqzfeTlyKrVF0piIbI+8FMyIsy0bLwkzZVVqpWK1zNlp7BpExIuAKWb0vSycMeFBnR43N+1R4pduhCTG/8Wo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon 24-02-25 13:36:50, Kalesh Singh wrote: > On Mon, Feb 24, 2025 at 8:52 AM Lorenzo Stoakes > > > > > OK, I agree the behavior you describe exists. But do you have some > > > > > real-world numbers showing its extent? I'm not looking for some artificial > > > > > numbers - sure bad cases can be constructed - but how big practical problem > > > > > is this? If you can show that average Android phone has 10% of these > > > > > useless pages in memory than that's one thing and we should be looking for > > > > > some general solution. If it is more like 0.1%, then why bother? > > > > > > > Once I revert a workaround that we currently have to avoid > fault-around for these regions (we don't have an out of tree solution > to prevent the page cache population); our CI which checks memory > usage after performing some common app user-journeys; reports > regressions as shown in the snippet below. Note, that the increases > here are only for the populated PTEs (bounded by VMA) so the actual > pollution is theoretically larger. > > Metric: perfetto_media.extractor#file-rss-avg > Increased by 7.495 MB (32.7%) > > Metric: perfetto_/system/bin/audioserver#file-rss-avg > Increased by 6.262 MB (29.8%) > > Metric: perfetto_/system/bin/mediaserver#file-rss-max > Increased by 8.325 MB (28.0%) > > Metric: perfetto_/system/bin/mediaserver#file-rss-avg > Increased by 8.198 MB (28.4%) > > Metric: perfetto_media.extractor#file-rss-max > Increased by 7.95 MB (33.6%) > > Metric: perfetto_/system/bin/incidentd#file-rss-avg > Increased by 0.896 MB (20.4%) > > Metric: perfetto_/system/bin/audioserver#file-rss-max > Increased by 6.883 MB (31.9%) > > Metric: perfetto_media.swcodec#file-rss-max > Increased by 7.236 MB (34.9%) > > Metric: perfetto_/system/bin/incidentd#file-rss-max > Increased by 1.003 MB (22.7%) > > Metric: perfetto_/system/bin/cameraserver#file-rss-avg > Increased by 6.946 MB (34.2%) > > Metric: perfetto_/system/bin/cameraserver#file-rss-max > Increased by 7.205 MB (33.8%) > > Metric: perfetto_com.android.nfc#file-rss-max > Increased by 8.525 MB (9.8%) > > Metric: perfetto_/system/bin/surfaceflinger#file-rss-avg > Increased by 3.715 MB (3.6%) > > Metric: perfetto_media.swcodec#file-rss-avg > Increased by 5.096 MB (27.1%) > > [...] > > The issue is widespread across processes because in order to support > larger page sizes Android has a requirement that the ELF segments are > at-least 16KB aligned, which lead to the padding regions (never > accessed). Thanks for the numbers! It's much more than I'd expect. So you apparently have a lot of relatively small segments? > Another possible way we can look at this: in the regressions shared > above by the ELF padding regions, we are able to make these regions > sparse (for *almost* all cases) -- solving the shared-zero page > problem for file mappings, would also eliminate much of this overhead. > So perhaps we should tackle this angle? If that's a more tangible > solution ? > > From the previous discussions that Matthew shared [7], it seems like > Dave proposed an alternative to moving the extents to the VFS layer to > invert the IO read path operations [8]. Maybe this is a move > approachable solution since there is precedence for the same in the > write path? Yeah, so I certainly wouldn't be opposed to this. What Dave suggests makes a lot of sense. In principle we did something similar for DAX. But it won't be a trivial change so details matter... Honza -- Jan Kara SUSE Labs, CR