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 1B2F2C5321D for ; Tue, 27 Aug 2024 02:49:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85E1C6B0083; Mon, 26 Aug 2024 22:49:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80DE66B0085; Mon, 26 Aug 2024 22:49:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D4DE6B0088; Mon, 26 Aug 2024 22:49:29 -0400 (EDT) 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 501C56B0083 for ; Mon, 26 Aug 2024 22:49:29 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 05247161570 for ; Tue, 27 Aug 2024 02:49:29 +0000 (UTC) X-FDA: 82496494458.17.0FE09A7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id AB07940008 for ; Tue, 27 Aug 2024 02:49:26 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cmr6GFy5; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724726948; a=rsa-sha256; cv=none; b=kStbc+8vEomgXUuCBDSYmA3m0oWdCzymdF+3yYN0/lK4QXPDZAfhUL5/edHSNGPbPXRair BijRJYeJkI+woZ06kbcAm3DUqqLk3ApS7FRIfsV/gF86Oohw7LACwAywA00FLJ56MKeGhr VtfWLswyeWuDsr+byZFT1V2zQY/M4E8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=cmr6GFy5; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724726948; 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=K+t1fgjuD7jQJs4t+TEAj0hOuvtJHd4crj62vRUGD+U=; b=4JjhXanrbQM6Xbq7s0VGTVuBXikA/sP+MXBiiqFZ7wGbVOIG2MVRq26wrjNfJAm/r/QMJI 7ppiiHBbE2+6CHeub8UzGF9mo/J4LPNxpSi8TvE3pThQnYhCWw8TRKVN810Yx8vXQGzV2i Rep7PjDdR6fWpCehqRuVijfEneKEGuA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=K+t1fgjuD7jQJs4t+TEAj0hOuvtJHd4crj62vRUGD+U=; b=cmr6GFy5R8N5mOQu+yEiHqE7p9 40VojD1abcu9SjXqQYyib3V25L8H+iBMjp9TGnOm/rlNvXomZjOHE0VfhGmVWvDedbU5KlbivtNj2 BBWUId3YC0ywu4GSCvaE+OFytH57t1klIBAKUr51OeQJ9YRK7FfhEo06WRNwN6qpeai0eXjA3woOo 4IGn8UcATOLbt534KrLDG6w9Fu0g+Qf9p36YUKBW54+6RWh6jY4QvE5/cSF8SnXu++XqWkMfGDcYd 3JKvG7C5gRJ5kUHb05/RvCDy2pV/S9sqzNzqqc7wmtzwLMAyynYldrbFUsji053QpdBHHg3454G1P iTr3kqvQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1simGc-0000000GIY3-34ce; Tue, 27 Aug 2024 02:49:10 +0000 Date: Tue, 27 Aug 2024 03:49:10 +0100 From: Matthew Wilcox To: Zhaoyang Huang Cc: David Hildenbrand , "zhaoyang.huang" , Andrew Morton , Yu Zhao , Baolin Wang , linux-mm@kvack.org, steve.kang@unisoc.com Subject: Re: [RFC PATCH 1/1] mm: Skip folio with private data during isolation Message-ID: References: <20240826085056.895865-1-zhaoyang.huang@unisoc.com> <38881e37-767c-456a-8301-2a7d0371d12e@redhat.com> <8ffc4e3f-bae9-4567-8eb7-f1b163309d7e@redhat.com> 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-Queue-Id: AB07940008 X-Rspamd-Server: rspam01 X-Stat-Signature: d4ifirrox1oh3r64bb9q8tp7omz579gq X-HE-Tag: 1724726966-250165 X-HE-Meta: U2FsdGVkX1+I/hvHV2UgUSQF4lV2KZvf69Vuk3gcZkMqN6rvCqmI3BN/xUIv4JDb9Y9GebrOqg6TkG5737OI04B90Oe5TlXBIf0xpg5Hg4rGleTWH1S4v9XmKiq/42gmtkiNTVvJlZIyKZvKWnwhHVQi2LTVcyQw2PwlMc8OP/FYBkLtOrBXVtvk8CiutvyItT2lpF6ZL5gxrb7sbnF7CtYK8UjWYZv2c2YnK3afyxAb8IHNz2w5374oV+aFmQ4C1veTrPfgw7/D9IrP+kcFsavovoC/LcKgtpoXOQmXai44x6sYgt80OOl0xeFnFtZVvWukR2iUq8I4qu99ntXyW5bmKUuRbBj4I/enxOVo5OoBh/V4oIHjsadU4u7Lx0RECjLy5Vbvhv13x+48i2ENR11/mmaKBbSo6dZX8sBqDLqsCwLnQOLTyPN+Y3h9YnDyBRLnPWsDh8RvoEdPbofHPMdEK2QRdf1Zl58OKjootwv9ftQKj+AZRY1hy5ZyRvTMz7NTuA5gOg3P35RQh1/p1PfTZQEXpc1bShEAIGxMV1o6vlktAOrgRuVbq6Ivs0UbjmWcsuQh6r36TXGwxSae9ySNar2TTdAJAGDPm/BnUxk584ChfFPOKqwp7XoHw1ig/PKQmpl6AwhSYnORYz2j7tx00zYrxN7O16YnyVYCO5LDADSv4mN+NSItNLXKbqFznPlhkxdp6AVcoEX58zGP6BpqD9w1HItBNxtu30cWadvN0nJyUjlCCe0FRZuH8gzkBxQaB4w6H8RR/buASfkq5Z9OkDxn7rEwN1/zGgtKSeG5ui/pIE1YKwcDQIYI3jT2/xJCldsA1ri4QWdU54QGOZSrTcdspkPfMCQjTm+XTE/+dSWpngVJptF/dwYLbSqHOpRkmgg1Lb9pVVLytJS+NHDwM3qoXtlS0AIbrV0EUaG53FBeGsmGun254kRQ5j68NixVWzgRv1DaWoWdqsM E/Dgg2jO mA0JPUDpczgFWR1TBVnkF1FEXEoew0xggbt+T7ryOa54+bgrcL2RgejnKCYdc6IwhE76Yoq5IP50c4uOMd9VvLTDLFCrQPRuon+SCreFyPNarRRxt2dWYEs+7m5GPEqN512gQ0gTZ5/XeomhQV3mY98UgZZysjLyO4fA8jsoMUxB2lxCJLq/wrDNjeGUWUH6CIJIzFIc479qSQNyRuDsJRYMvmoB166yK7j6aOImGNzDm7/Efgua4Irtox22LK5rNOvBy 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 Tue, Aug 27, 2024 at 10:45:11AM +0800, Zhaoyang Huang wrote: > On Mon, Aug 26, 2024 at 9:01 PM David Hildenbrand wrote: > > On 26.08.24 13:10, Zhaoyang Huang wrote: > > > On Mon, Aug 26, 2024 at 6:36 PM David Hildenbrand wrote: > > >> An earlier filemap_release_folio() would have failed if the private data > > >> (buffers) cannot get freed, and we went into the activate_locked path. > > >> > > >> if (folio_needs_release(folio)) { > > >> if (!filemap_release_folio(folio, sc->gfp_mask) > > >> goto activate_locked; > > >> ... > No, this is actually a migration failure issue[1] related to cma_alloc > where the bh keeps busy as the journal's transaction can't be > launched[2][3][4][5][6]. I am just inspired by this issue to check if > there is anything to do in reclaiming. By counting from a ramdump, > there are 300MB "lru, private" pages found in a 6GB RAM system which > could lower the reclaiming efficiency if the same scenario as above > happens. As David said, if we encounter a filesystem folio with private data, we ask the filesystem to strip the private data off. Usually this succeeds, because most folios aren't part of the journal for very long.