From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 688FD3655D8 for ; Mon, 27 Jul 2026 08:08:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785139710; cv=none; b=LWJICRU2sDgY122hy6fwkKV73urI6YbMCdVrosth1tswLwRN4hWwYVR3fmOLTeaDIxfwYmQ5fkXDBsP0MLvcdZxNWhJ1bImX7Xeeed0AJCKyKajSG+up3rvCfg7felgXsVDA4Mezqj+hDjDX6nTzPtiGJQyvFEtxBWVrlVeJsBc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785139710; c=relaxed/simple; bh=UO2tffCzhKaPt2gk6QycGbyZgp4QpW1TuzncuX9wD2s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VqwYhEm+/ydJvnYk/w8HvqvT+Gx6Q0WGB6+pkevnPzGkaN82IUKsNPh5tmZ9y73IsLpqDiB5Hx+4Go3i8yfCkNlmd1w8aQaZS4GNG/oDyXgvChBxmI68+g4iIBMoQrZy5blI2s4Mxv0AUzEz3ObWu1Dr4jnjuLAkjbkIpFj5o9M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=SMqq1QkZ; arc=none smtp.client-ip=115.124.30.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="SMqq1QkZ" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1785139703; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=J6HLmhjbpj99T3EygYwInaeiofORC8oNhZgRbwCAD4Q=; b=SMqq1QkZZsrOq/L7gjoyZNtAdVTjYk3A5V3j0r2uAnapzMHVpHYdYCSlvWDC+PU3FVJvbxfVM2yq71i43fZCSUlyzcklhOb1y8iJoTYH8q8wKPoFVK4DY7bn6XWyMuXh41byqGgxI5NMTaj8u0ot0dssOaFx7nlRfozuaTh4wLM= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=23;SR=0;TI=SMTPD_---0X7rqjGN_1785139699; Received: from 30.74.144.127(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X7rqjGN_1785139699 cluster:ay36) by smtp.aliyun-inc.com; Mon, 27 Jul 2026 16:08:21 +0800 Message-ID: Date: Mon, 27 Jul 2026 16:08:19 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/3] promote mapped executable folios after first usage for MGLRU To: Zicheng Wang Cc: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, hannes@cmpxchg.org, riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, lance.yang@linux.dev, kasong@tencent.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, mhocko@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tao.wangtao@honor.com, zhangji1@honor.com References: <20260724160000.b4-mglru-feedback@hihonor.com> From: Baolin Wang In-Reply-To: <20260724160000.b4-mglru-feedback@hihonor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Zicheng, On 7/24/26 4:00 PM, Zicheng Wang wrote: > Hi Baolin, > > We backport and test an Android handset(qcom8850, 6.12, 12 GB). > Patch 1's vma_flags_t isn't on 6.12, so we kept only the core > check in its legacy form: > (vma->vm_flags & VM_EXEC) > > Since this is a backport, the numbers below just show the direction > of change. Overall the patch does well, and ran for several > hours with no crashes or hangs: > > Camera (launch + capture, 22 background apps resident): > cold-start p50 -6.3% > capture on par > memavail at startup +4 .. +7% > > Reclaim over the same window, as the patch intends: > pgsteal_kswapd -46.5% pgscan_kswapd -52.9% > pgsteal_direct +0.8% pgscan_direct -6.7% > pgsteal_anon -13.8% pgscan_anon -13.8% > pgsteal_file -14.5% pgscan_file -30.1% > > Dynamic jank (cold start + scroll, x10): missed-frame <1% on both > base and patched; not memory-bound enough to discriminate. Thanks for testing and sharing the performance number. > One trade-off, same run. PSI (memory) creeps up on the sustained > window: > > avg10 avg60 avg300 > some base 0.00 0.03 0.33 > some patched 0.00 0.02 0.37 (+12%) > full base 0.00 0.00 0.10 > full patched 0.00 0.00 0.13 (+30%) > > and kernel stack footprint -5.3%. Reads as LMKD keeping fewer > background apps alive. This seems an Android policy interaction, > not a kernel regression. Downstreams with aggressive LMKD may > want to retune. I didn't pay attention to PSI before, but I think this is explainable. Since we try to keep executable file folios in memory to avoid IO thrashing, which could cause more severe problems (such as the system hanging), this also means that the stall time of some other folios may increase. Moreover, the stall time of the original exec folios might not have been counted at all, for example, in filemap_read_folio(), PSI is only accounted for file folios marked with workingset, but before my patch, exec file folios might not have had a chance to set the workingset flag. However, the overhead of IO thrashing is more severe than the stall time of other memory allocations, which is why the end-to-end performance improves, as seen from your data.