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 6D767C4167B for ; Tue, 14 Nov 2023 09:50:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C57728000B; Tue, 14 Nov 2023 04:50:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C071280009; Tue, 14 Nov 2023 04:50:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA7318000B; Tue, 14 Nov 2023 04:50:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 970DB80009 for ; Tue, 14 Nov 2023 04:50:51 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6C878B5A1E for ; Tue, 14 Nov 2023 09:50:51 +0000 (UTC) X-FDA: 81456090702.06.8AA3BD1 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf17.hostedemail.com (Postfix) with ESMTP id 4944E4000B for ; Tue, 14 Nov 2023 09:50:48 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=o9+byrf9; spf=pass (imf17.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699955449; 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=Xk27T3NxTwbnlJ5P3tH7QSavlHidd8/4W2N+WOglPOs=; b=w/eAPi9rAMPs0WYIhv0Wm1D9GBti3krOtXvoeuRrmBGr+6/ymHQev7XROJaHzqU7krL/fr fyb0sKj8OrVEl3pjpRUJv537+149HIvBERERwAeJDaZDTBCtk6BtfZeNBnEaI+0ANdRGeK 1vVyRaD8DYSlUlGzH+RomE7Rf0ZDB2E= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=o9+byrf9; spf=pass (imf17.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699955449; a=rsa-sha256; cv=none; b=5gVDJZKKClcyG5DdvL6EaMF5NyjD/+9Mu29vECi/9q2YxRp2pUQBbVvLmutonFCqzMSfWc faLesia8B6cS1dwhagymCWAyQVlHO+mMttTztGAd1hFz3CGM7LoX82H42shVtWn2YRd8Qq V967qZJcWzHOpQutdlbZBCgkCWXRi3w= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 66AAB218D6; Tue, 14 Nov 2023 09:50:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1699955447; 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=Xk27T3NxTwbnlJ5P3tH7QSavlHidd8/4W2N+WOglPOs=; b=o9+byrf9oaOteVJp06CiArSYrYnZpqhQXZmvmMM5LOiuPUsTg8RzF/X5qetT9q4sS1a4i/ uujODQOVmJnUNizVf1cLqjYuavqPDYK5rt0HDcoost94BdF9NCVeU8aO0n46pt9y0zLB4B 9VbdGAnoF+RLE8+GtvsEqo/PON4evFg= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3BDD813416; Tue, 14 Nov 2023 09:50:47 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 3RVnC/dCU2U1HAAAMHmgww (envelope-from ); Tue, 14 Nov 2023 09:50:47 +0000 Date: Tue, 14 Nov 2023 10:50:46 +0100 From: Michal Hocko To: Huan Yang Cc: "Huang, Ying" , Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Kefeng Wang , Peter Xu , "Vishal Moola (Oracle)" , Yosry Ahmed , Liu Shixin , Hugh Dickins , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, opensource.kernel@vivo.com Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim Message-ID: References: <6b539e16-c835-49ff-9fae-a65960567657@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4944E4000B X-Rspam-User: X-Stat-Signature: yiaayw1jcabgyq5nmw5d719xbj3zn9ar X-Rspamd-Server: rspam01 X-HE-Tag: 1699955448-557734 X-HE-Meta: U2FsdGVkX18xlZgZ+Q6WvCYN4yKX730Fr4Iu4OLQs2z380/ACss1wJUuJFZRmL0m3XGho+BmyX+rqQjZC0fgrLnGsnWPxNwzWoEzZY0R+5WxmuCJpEAU5DDS0EfUpHQ8EHCmhX5RgZ3bDKoekQjQVo6vMpkxAt4NY3/SsBINrzf9uKv0MCJYdnKB+J9PI0tTf60eC8t8J8nb0uZD//dexPDoYRhmYU6BxIG0VbDt1iJMR9j9iXlysB7/ZwFBrOjmB4w906MgRbZWh6fu+U1aEyW3Y1GbKAtCCXXqvuny4HsAP5ORM07ITRtGTaWXiThWVcxD+QAGejlqWCgGsNu02KzAMO5QZFjaVO5RpS8yV/V4yW/4tI9i1Twt6nIZRwApY2t3o8+iOzqhjEYWzTaCXdA0RfKYxKrR7OtYICj97Fwj0hqMsG+0trbQsseGW4YcjxtKzvpmWx6ICaolDK+YsfbHz37Ro/eXIgFbjulfdpxoo++UQQPUAtN4WHN8d+m9Jqcb4F9ZWYpbQvI2oNgaHym51ufC93hXkg6e1mE6hfIrQfveZNL8nphLoqcopF0Jx/sCBwbEpJglizItozH2h+9BtiHfVmFlxWB8O50mM5cnUbh2xqwTDBUwjOZoCemayrTiJ81EZwJNPCYlpQ67x3M+V4UX88WqJMUI395/uLgitGslMzu0UiGZqjqLvoFGdlMAG012qy94mO7i+FF9UJWjcAYIaP280kf3tYPJEn0w5a1jHqBILE9b/TCxYBccCL4PlDoJRueo9isoqtrWv27B3cQdtH8NnS89fIfu5haiRcVDCvxhjub2K0HHILbA29xnTCanVjiM7tzWNd88cm/bFmVY6fxBxe2tJHHjodnNynovFgpLzTYu90jamNtN6tN8QxwXngEoca2evXO27i1+CQ6c3EkX/28KzvnG6s9xvAESrXaaspYNvmgcO3bTR7szY5Q2PQ26ExP+Fn0 mTzOUnSI V7ES2RXrmeqcJXkLE+ok5kw57pI5+bhEsU9yg22PRiQjIdHg3NPFsdwIrJ9BSNNxcazBoz9tXjeSj6a8Z2R86ZmoUspb1hDEKe9lv1u5mY5Pzhp9duMVBDUiQvU+NE1r+RIsJ/zPs8FgrMRDkR75cKpjdEn6mQ6+wy2+GDddrVWV/1L0dnY+QJmaLjsBha2IpRxEtEnDvxspaYXpBAjoT341/rF8hbxsJBxLBYVHjkt8hVkjX56vdJmwoOiQOfvtA2iWq 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: List-Subscribe: List-Unsubscribe: On Mon 13-11-23 10:17:57, Huan Yang wrote: > > 在 2023/11/10 20:24, Michal Hocko 写道: > > On Fri 10-11-23 11:48:49, Huan Yang wrote: > > [...] > > > Also, When the application enters the foreground, the startup speed > > > may be slower. Also trace show that here are a lot of block I/O. > > > (usually 1000+ IO count and 200+ms IO Time) We usually observe very > > > little block I/O caused by zram refault.(read: 1698.39MB/s, write: > > > 995.109MB/s), usually, it is faster than random disk reads.(read: > > > 48.1907MB/s write: 49.1654MB/s). This test by zram-perf and I change a > > > little to test UFS. > > > > > > Therefore, if the proactive reclamation encounters many file pages, > > > the application may become slow when it is opened. > > OK, this is an interesting information. From the above it seems that > > storage based IO refaults are order of magnitude more expensive than > > swap (zram in this case). That means that the memory reclaim should > > _in general_ prefer anonymous memory reclaim over refaulted page cache, > > right? Or is there any reason why "frozen" applications are any > > different in this case? > Frozen applications mean that the application process is no longer active, > so once its private anonymous page data is swapped out, the anonymous > pages will not be refaulted until the application becomes active again. I was probably not clear in my question. It is quite clear that frozen applications are inactive. It is not really clear why they should be treated any differently though. Their memory will be naturally cold as the memory is not in use so why cannot we realy on the standard memory reclaim to deal with the implicit inactivity and you need to handle that explicitly? [...] > > Our traditional interface to control the anon vs. file balance has been > > swappiness. It is not the best interface and it has its flaws but > > have you experimented with the global swappiness to express that > > preference? What were your observations? Please note that the behavior > We have tested this part and found that no version of the code has the > priority control over swappiness. > > This means that even if we modify swappiness to 0 or 200, > we cannot achieve the goal of unbalanced reclaim if some conditions > are not met during the reclaim process. Under certain conditions, > we may mistakenly reclaim file pages, and since we usually trigger > active reclaim when there is sufficient memory(before LMKD trigger), > this will cause higher block IO. Yes there are heuristics which might override the global swappinness but have you investigated those cases and can show that those heuristics could be changed? [...] > > It is quite likely that a IO cost aspect is not really easy to integrate > > into the memory reclaim but it seems to me this is a better way to focus > > on for a better long term solution. Our existing refaulting > > infrastructure should help in that respect. Also MGLRU could fit for > > that purpose better than the traditional LRU based reclaim as the higher > > generations could be used for more more expensive pages. > > Yes, your insights are very informative. > > However, before our algorithm is perfected, I think it is reasonable > to provide different reclaim tendencies for the active reclaim > interface. This will provide greater flexibility for the strategy > layer. Flexibility is really nice but it comes with a price and interface cost can be really high. There were several attempts to make memory reclaim LRU type specific but I still maintain my opinion that this is not really a good abstraction. As stated above even page cache is not all the same. A more future proof interface should really consider the IO refault cost rather than all anon/file. -- Michal Hocko SUSE Labs