Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <233c1c9b-963b-4129-b26d-f1f74c8595ad@vivo.com>
Date:   Thu, 19 Oct 2023 14:29:52 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] mm: multi-gen lru: fix stat count
To:     Yu Zhao <yuzhao@google.com>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Suren Baghdasaryan <surenb@google.com>,
        Vlastimil Babka <vbabka@suse.cz>, linux-kernel@vger.kernel.org,
        linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org,
        bpf@vger.kernel.org, opensource.kernel@vivo.com
References: <20231018082104.3918770-1-link@vivo.com>
 <20231018082104.3918770-3-link@vivo.com>
 <CAOUHufbPiAhpvHuo=oH7Zhyoc0hR-6kpVrCEe-b0OuWYWne2=A@mail.gmail.com>
 <a2373558-920a-49b1-91ac-9b0a6a1468b2@vivo.com>
 <CAOUHufYiu-5wEkNnrt+HdnwHTZ+5FytqBB-j3nuHS5kgY+c3ew@mail.gmail.com>
From:   Huan Yang <link@vivo.com>
In-Reply-To: <CAOUHufYiu-5wEkNnrt+HdnwHTZ+5FytqBB-j3nuHS5kgY+c3ew@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Lzk2dXZ0NStEcUlHNy9wUUtFUDc0SFVRdVZTNmFBbkh3SDRJMmlIM0tWZE1T?=
 =?utf-8?B?akxBbXl6QXk2TEJBWXdaVWNtMkpreExxM2RBVlBsS1I5SGVVOXNUek1mbkZj?=
 =?utf-8?B?MHdkTVBzdkRrUFlPYXVjeHp3bTlpckc0dmFTNTVTa0w1SWhZRWlWZUkvaWln?=
 =?utf-8?B?R0pBN2FOUTFlaGs1OG8zVEhmZzVqSld1aHZxeVNyVTk4WmsvdTlKa0F3ZEFP?=
 =?utf-8?B?MTRnbjBucit3QU1JeGVHYllQWjduNkxwNTRJZFVTcHlBSGl6UmVVNG1mVXk3?=
 =?utf-8?B?QXVqTnVFTU4yRVZaVk1zQXFsNm5YWTF0Y0lZbTlmYzg5VTFOZnZCeEt5ZzNv?=
 =?utf-8?B?d2Q0Y3NiRE9zWmw2R3V1eDVtNXljQ1lrN0o2dVBQSTBGWXBwekNFaWRNYndC?=
 =?utf-8?B?OVdkemxER3ZVcms5RHhFZ0x4d0VzSWp0d21tS0FxSi9WT2dLY2Izb1FFWHVI?=
 =?utf-8?B?Wk9YVEpZTVJKVHdCVldMZXJNdlVtNmNVd2R6cnR2VW9hQW5aUlRiOXArSVIz?=
 =?utf-8?B?MHh2dm13YjJ1Y1NaaDVYRnQ2aE9yekRWajl2VndmZmU2SkE1eXlyb3ZpcVlU?=
 =?utf-8?B?SDcvRDRZNTJRaFJaNzQ2OFNRcmhsMXQ5ZGg0MVN2RFRlRmRFMTdxSUVkSzVD?=
 =?utf-8?B?Q2JNM1k2VVQ4UHBzUFVwYUwwcjhuZThUV2lMTEV4SFpqU2hRS3ZZTzNHNlpY?=
 =?utf-8?B?eE4xMTJUaUo0M3M0aXYyQjJ4OStSdFl1bmZDemlJUHl5a1l4WS84WkRIMjlO?=
 =?utf-8?B?THQxMnFXOVhvRG85UUNhMGhUcGxPQlVvSXcyS2M3TEhKODNDV3lkcThxTFpn?=
 =?utf-8?B?ZTUyWG9rY1VMeGJ3RE5tZFdRNDk3aVZrdlNJSkFlMHBqN2V2MUtONHZxbWtn?=
 =?utf-8?B?ZUtyR1FpS1FqRzYzY3ZrOXliQmNTaDFOWmhQQ2Z3ckpLOGZSa0JXZ0FST1ds?=
 =?utf-8?B?Wi9SM1Nld2xIdGVPNzFRdVRWSHljMGtZNDEzZyt0M1YwSG5wRW1RNVhPb0ov?=
 =?utf-8?B?NzNkK0tDRnlFYWFNRUVyc3B1WFg3QWx2eDNMdExWVjVvNkxiYzMwWWtRZ0Iw?=
 =?utf-8?B?dEg2SmtXMW5QZjRjbzBZaWZYS2VsVlFINnZwaXFHeGI4YnJhRFMyVzRaSFh1?=
 =?utf-8?B?WFBUYVAvSGFlT2l0OXRudXU3N25NRjRkaGpDTTBHZ01zQzhiU091NmRNeExk?=
 =?utf-8?B?YzAzTnAwcUpXTWlBOUg4clpneFBDL1BKVXdkeUtmV29BQk5UbmtsOWlNeisx?=
 =?utf-8?B?LzhSTHE5b3RtWTlESk5kbHl1S2hNdFhnUkR5akNyRmNwY3FYNmlKRTQ0Wm1Q?=
 =?utf-8?B?endCV05PNTlabWxqTTJ0RUxZZS8vckxpSlRqZ3JUcUZvNWZZLzZxUjFqZitn?=
 =?utf-8?B?cEZBRDZrYSswTUpJRWtCREN5dWtTU3lDc1R6eHdib2k0N2lNQm1yRWdhdGFN?=
 =?utf-8?B?VnZVZTM2SFJPczhPc2xsejVJbDdzV25heGsvUHVHU0Z5M2J0bEUydi9OWC91?=
 =?utf-8?B?Vkd3ZnJXdTUwS1dUSm01UTZLNXVnZG9kOEJVMnJVUXBZQVc5V3g1MGVqNU4r?=
 =?utf-8?B?U01lVjdkamN3NDE2NVJZS1AwNWkrUVFUc1RzbEVPQWlMNDJ5MEhNR0RSeDNr?=
 =?utf-8?B?NWcrT255YlZoR1hIcWtyT0EvM3FUb1VvOXBNa0Z5ZHM1cUZiRGE3aXlTWjA4?=
 =?utf-8?B?blB0VG5ya2dCSWNmRVYxNWM1dXY0MGtOdWljdStBSTJacW9oa0hwKyt5T0ox?=
 =?utf-8?B?ZktCWkdXcWV1Yk1XTXVxUy9uMDFndnBPZ1lBemovZXM1SkdFdlVZbS9CSGli?=
 =?utf-8?B?cFdTZDF1ckkzRjlmeGVOYzlEV2NoQ1AxMEk5ZEVpOW9VejBocDNCeEw3dHA0?=
 =?utf-8?B?MHRkYmZwY3NWU2FMOU9EY2YzcUZRcGJLTlgwQkppVEdqRUg4cFVpTDFqRzA3?=
 =?utf-8?B?VnkzUU1VNHhtanh6SVBZVDBVWVZteG1MSUpDcnppbGUwcWRMbzJvL1Uzdkla?=
 =?utf-8?B?NGZxVllDNnkxd3pLditneU9DbTZDb1VaRzljR0l0NmRwY2dlV3FZcWxDbmNt?=
 =?utf-8?B?NmVINkFQZzI3U2htZWNNR3U3S1hGczlRNnBjTFlSQngwWXhqQnl3VlpoSERE?=
 =?utf-8?Q?TT7Fg3iya1ZiARL/gJBp1fkN5?=
X-OriginatorOrg: vivo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 83e6445b-13a0-45bb-ed53-08dbd06cd004
X-MS-Exchange-CrossTenant-AuthSource: PUZPR06MB5676.apcprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2023 06:29:57.0558
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: N88OmP0g95w0zPqvJz2Hr8ZaficMXvT/qnsC41D7Fk2uowGbMcxIm+64nLBQpwR/C7Y3oq5EZeCHQEePyuIfxA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR06MB6985
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Wed, 18 Oct 2023 23:30:22 -0700 (PDT)


在 2023/10/19 10:39, Yu Zhao 写道:
> On Wed, Oct 18, 2023 at 8:17 PM Huan Yang <link@vivo.com> wrote:
>> Hi Yu Zhao,
>>
>> Thanks for your reply.
>>
>> 在 2023/10/19 0:21, Yu Zhao 写道:
>>> On Wed, Oct 18, 2023 at 2:22 AM Huan Yang <link@vivo.com> wrote:
>>>> For multi-gen lru reclaim in evict_folios, like shrink_inactive_list,
>>>> gather folios which isolate to reclaim, and invoke shirnk_folio_list.
>>>>
>>>> But, when complete shrink, it not gather shrink reclaim stat into sc,
>>>> we can't get info like nr_dirty\congested in reclaim, and then
>>>> control writeback, dirty number and mark as LRUVEC_CONGESTED, or
>>>> just bpf trace shrink and get correct sc stat.
>>>>
>>>> This patch fix this by simple copy code from shrink_inactive_list when
>>>> end of shrink list.
>>> MGLRU doesn't try to write back dirt file pages in the reclaim path --
>>> it filters them out in sort_folio() and leaves them to the page
>> Nice to know this,  sort_folio() filters some folio indeed.
>> But, I want to know, if we touch some folio in shrink_folio_list(), may some
>> folio become dirty or writeback even if sort_folio() filter then?
> Good question: in that case MGLRU still doesn't try to write those
> folios back because isolate_folio() cleared PG_reclaim and
> shrink_folio_list() checks PG_reclaim:

Thank you too much. So, MGLRU have many diff between typic LRU reclaim.
So, why don't offer MGLRU a own shrink path to avoid so many check of folio?
And more think, it's nice to assign a anon/file reclaim hook into 
anon_vma/address_space?
(Each folio, have their own shrink path, don't try check path if it no 
need.)

>
> if (folio_test_dirty(folio)) {
> /*
> * Only kswapd can writeback filesystem folios
> * to avoid risk of stack overflow. But avoid
> * injecting inefficient single-folio I/O into
> * flusher writeback as much as possible: only
> * write folios when we've encountered many
> * dirty folios, and when we've already scanned
> * the rest of the LRU for clean folios and see
> * the same dirty folios again (with the reclaim
> * flag set).
> */
> if (folio_is_file_lru(folio) &&
>      (!current_is_kswapd() ||
>       !folio_test_reclaim(folio) ||
>       !test_bit(PGDAT_DIRTY, &pgdat->flags))) {
Thanks