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 92AF6C77B73 for ; Sun, 23 Apr 2023 09:49:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 98E726B0072; Sun, 23 Apr 2023 05:49:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93EAB6B0074; Sun, 23 Apr 2023 05:49:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 806B56B0075; Sun, 23 Apr 2023 05:49:19 -0400 (EDT) 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 5A79F6B0072 for ; Sun, 23 Apr 2023 05:49:19 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CC06A1A01CC for ; Sun, 23 Apr 2023 09:49:18 +0000 (UTC) X-FDA: 80712182796.19.3E6836D Received: from r3-23.sinamail.sina.com.cn (r3-23.sinamail.sina.com.cn [202.108.3.23]) by imf30.hostedemail.com (Postfix) with ESMTP id C8DC98000B for ; Sun, 23 Apr 2023 09:49:15 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.23 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682243357; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=clv0MDlH/UllCw73+asPh87TznXLQTSi6db96w46Fq0=; b=l42eTOq/ed5CfRK8ladbi96zI9CEuyITQu7PVqL2k+Bl4HNIS7vamhTTo7Ql4Ct/ydA6/+ g6vGEHUWj0DJCLV1Y5yjOARjwEgLnT9NTaTiB0KoYzjCg2fxIV5FFSBuuc9qvxIALdroQJ HkpTj0v1dwQlUCaNMK/hGoPG8Q63gy0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.23 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682243357; a=rsa-sha256; cv=none; b=4I/YeOlA6sotdUtVpn2/NO3kFeIZAF7GBcGAcoarcKDMQDTvlsqXUZ2grQsd2JNpVe0C95 bdQE75V7XkeNtlm2GIi+C+QEaWE3AAwuQvj8n51mTA6YaieFzOZcugEjd8uc6vFfpWfDdW pcWUNlyMl8RDoB1GMZBEnwdIrK2V5+8= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.59.75]) by sina.com (172.16.97.23) with ESMTP id 6444FF16000318AF; Sun, 23 Apr 2023 17:49:11 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 73569631458313 From: Hillf Danton To: Gao Xiang Cc: Andrew Morton , Douglas Anderson , Mel Gorman , Alexander Viro , Christian Brauner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Yu Zhao , Matthew Wilcox , linux-fsdevel@vger.kernel.org, ying.huang@intel.com Subject: Re: [PATCH v2 1/4] mm/filemap: Add folio_lock_timeout() Date: Sun, 23 Apr 2023 17:49:01 +0800 Message-Id: <20230423094901.1867-1-hdanton@sina.com> In-Reply-To: References: <20230421221249.1616168-1-dianders@chromium.org> <20230422051858.1696-1-hdanton@sina.com> <20230423081203.1812-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C8DC98000B X-Rspam-User: X-Stat-Signature: cxpg8rb639za4zuhgb5skrtxbutby8x3 X-HE-Tag: 1682243355-745779 X-HE-Meta: U2FsdGVkX195ClzEzUHOkUnUKlsV8EBH6dQhuZrszsJdfic2iUkv0RuywnkXrA4C0PYN1IEcjk5MEqSpYxc9XDLwlfO9fQ1dGXXhIkbIlUCsPX/fvxxbgHZAD19qQBBUdSEwudgh2k44s6Aec4l/RDXziqrUZiUx/nJy2Fx0iw/hb0oBJZ5TldaIxAwmW6iOeUXJe0GZ2UQ0csSYrl2vzwD45MS4yaTv0w6VLH+aZ459ziG+G9aMreb5NCgtzr2nHyt6txXD3WLcGudDeFORVCS7gBfbSrZiDHBuByJ2SDQSOFEMBH0CvYbQiE8bPw4l6L850OgmIN8z4pYSHZk9M3f/5HxY4fYC9t1MmrmAYasQuLIBVc/0s1Y0/QGLHi4RKSgdHTZfgbHPa1Rq61cWZbCYzWoXEJpZXmBiNkVkLkPzLN+wz/dlF0anyBihqbKLkQMm5wyZI9sANn0tCnAkSZJ8kzO44lyBgqTGMfUnX99MUmo0xewRXA3w7r/QsNi84mx1KW3XqmJCt14Sw+KXnEc/I1gvvTqO+e5yi5AFJrOjHBW7Q2hw2Ygf8F2YFCX4W71ymwkdopQcW6V4ePNUnkT/8krijNVckeLuw+7qO++HiVdV/NGx3Ard5Pe5x1youFJeyjCVO0B0xknoMg4EQG8e339R3EKr/KqyM+7KgRQzgNXvs6Qq7UgyTRmEDoc/GMFLKz0elxzX2b5fSuRf23oBVEvHvzXKgkrsR6MSRIbVvCpJ5yfy57N9Oq8ZY/uAGFaZDwUOhKbDgMH8RXORXskbFEFMWyiBX3p/KelQdh9sqAG39d3E7MrozH9mjJN9622C5pU0iACCJ7Z7dbJWKEwH3cjfjeLyba5BGhgAp1+LBwXoBfz2XxbizA6vfDBqONPuKjqeG2rDFbUbGkbou139ym2FkXUDRYJSsOPWkcmLBikrKVVmYQksgCULqPAcOm5pGRvwy20SniCxgg3 ScGrA/VB ozVyks6iVH50ElRoKL1m7m7hBAdRWVsUIgO11p725X3CaNjhHbfQyNb2R1uyPTXY3uLv/Ch9XeguoApMPru1YQ7OyDnFGJGUR76m6RiXyR6pAswKVC341vwkQumuKnu4czbecI5hT3UOQkP+poZEIZe9CKVyFfJsq2evexQVB79yQ/D/yI/tLvk9QZL7zCwNcSrYSv/HwLK2eh0YRyBCWXeZf6C9WyZ/jv5begUJvnlCYAHJI5ZSDTxeUHNazTV7gWMvmWnaxfBuC57NDNcd3Xeq1EEyc+kRRGyIuJaAYFZzx0NEGziT/zyr8KupgfQznvCkE4xh93KpivTM= 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 23 Apr 2023 16:35:26 +0800 Gao Xiang >On 2023/4/23 16:12, Hillf Danton wrote: >> On 23 Apr 2023 14:08:49 +0800 Gao Xiang >>> On 2023/4/22 13:18, Hillf Danton wrote: >>>> On 21 Apr 2023 15:12:45 -0700 Douglas Anderson >>>>> Add a variant of folio_lock() that can timeout. This is useful to >>>>> avoid unbounded waits for the page lock in kcompactd. >>>> >>>> Given no mutex_lock_timeout() (perhaps because timeout makes no sense for >>>> spinlock), I suspect your fix lies in the right layer. If waiting for >>>> page under IO causes trouble for you, another simpler option is make >>>> IO faster (perhaps all you can do) for instance. If kcompactd is waken >>>> up by kswapd, waiting for slow IO is the right thing to do. >>> >>> A bit out of topic. That is almost our original inital use scenarios for >> >> Thanks for taking a look. >> >>> EROFS [1] although we didn't actually test Chrome OS, there lies four >>> points: >>> >>> 1) 128kb compressed size unit is not suitable for memory constraint >>> workload, especially memory pressure scenarios, that amplify both I/Os >>> and memory footprints (EROFS was initially optimized with 4KiB >>> pclusters); >> >> Feel free to take another one at 2M THP [1]. >> >> [1] https://lore.kernel.org/lkml/20230418191313.268131-1-hannes@cmpxchg.org/ > >Honestly I don't catch your point here, does THP has some relationship with THP tests ended without the help of timeout helpers. >this? Almost all smartphones (but I don't know Chromebook honestly) didn't >use THP at that time. >>> >>> 2) If you turn into a small compressed size (e.g. 4 KiB), some fs behaves >>> ineffective since its on-disk compressed index isn't designed to be >>> random accessed (another in-memory cache for random access) so you have >>> to count one by one to calculate physical data offset if cache miss; >>> >>> 3) compressed data needs to take extra memory during I/O (especially >>> low-ended devices) that makes the cases worse and our camera app >>> workloads once cannot be properly launched under heavy memory pressure, >>> but in order to keep user best experience we have to keep as many as >>> apps active so that it's hard to kill apps directly. So inplace I/O + >>> decompression is needed in addition to small compressed sizes for >>> overall performance. >> >> Frankly nowadays I have no interest in running linux with <16M RAM for example. > >Our cases are tested on 2016-2018 devices under 3 to 6 GB memory if you >take a glance at the original ATC paper, the page 9 (section 5.1) wrote: >"However, it costed too much CPU and memory resources, and when trying to > run a camera application, the phone froze for tens of seconds before it > finally failed." > >I have no idea how 16M RAM here comes from but smartphones doesn't have >such limited memory. In brief, if you runs few app, you have few problem. >but as long as you keeps more apps in background (and running), then the >memory will eventually suffer pressure. Given no complaints in case of running 16 apps with 1G RAM for instance, what is the point of running 256 apps with the same RAM? And adding changes because of ill designed phone products?