From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outbound.st.icloud.com (p-east2-cluster4-host4-snip4-10.eps.apple.com [57.103.78.151]) (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 8438938655D for ; Thu, 11 Jun 2026 09:24:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=57.103.78.151 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781169842; cv=none; b=piDUpdVRUyjCikExHLJiSRdxMyvfOSufUNZl8OQUC0AYGsPgpVTEGfh/IZY96xgq++kPqFwd5Wel4XAF+NGhQRHaG7AanDsddmvLvhS6uLPVm0BmbsXyrT4oqVW3GYvS+STCSjckpbrFFiLGiWsLpOJX63SvMlrS5MTVbLejfww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781169842; c=relaxed/simple; bh=VTUDLQ+tB+/dEE+MvmMbshrgGc1P3q23aP31rEi0+IQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ueeJTnqpPtEMYyWjudIaN3WvVBrj9zMqdMD+EbxYHN9kYBuBhN6sVV3z/APeti7KY6d7lKRWz7KRkwoBgWaGQsy9jv5EFrHGJZsAX+AXOQS3gvTo0YhnE0cElANmfgTTWFm0Sb7JVPHqFMcGeLvMQbJxlvqBqMSEgR+pxefu2AA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com; spf=pass smtp.mailfrom=icloud.com; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b=BLK+9v4l; arc=none smtp.client-ip=57.103.78.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=icloud.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b="BLK+9v4l" Received: from outbound.st.icloud.com (unknown [127.0.0.2]) by p00-icloudmta-asmtp-us-east-1a-60-percent-4 (Postfix) with ESMTPS id 73ED4180026B; Thu, 11 Jun 2026 09:23:56 +0000 (UTC) X-ICL-Out-Info: HUtFAUMEWwJACUgBTUQeDx5WFlZNRAJCTQ1LHVwEWRxBDUkdXwdLVxQEFEYGVg1dE0wLcwRUB10FXVZQAlpLVBQEEVABWB5WXloXXk1FCA9CAVhbCFsEDx9MDFECQgVWXkoMHQRUB10FXVZQAlpLQgRLRWhcBVwcQBdIHV9qS1YUBBFQAVgeVl5aF15NWgJWTQUZWh0aG1k/UiEeLkADcDZeOH84fCpwMXBVfi4GVRIEQAhWUF4IXh9MHA== Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1781169840; x=1783761840; bh=Yruy+uDSwynGDVg5p2NykKBJLXswuax2VIEq8rPzrwE=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:x-icloud-hme; b=BLK+9v4lXZLgJl0JsJ6MpHx39olx+zw4FQL/tmQNPy2jRLxxpQ4DuspOXV2kYzWM7Y494lfNEytXzx0fi0lZjtRArjT/8Ks1QlKUcb0Q7r8kxr3Eo4x1DQAaNfw7mAxBAXfOOEQjCby5KNKROFXhMtJDesvxMVFNiaJzTWxBuZM+07mCu8lMjF2Ngo1a0vRwuuOZCqVgsXnZbVVVKGMpWllBPfbi2BLsx5+QwOhZQICaDu6nWGJxx5Mus+1v9rQcqdvXOMQnRBm7bEm3Y6934kuzAu9IFOxbNp/LQGPihAvrXlq2hQeFIOC682wm9BefHKeKb3MyRzFCyYuWWLwiOg== Received: from localhost (unknown [17.42.251.67]) by p00-icloudmta-asmtp-us-east-1a-60-percent-4 (Postfix) with ESMTPSA id 351E3180024A; Thu, 11 Jun 2026 09:23:55 +0000 (UTC) Date: Thu, 11 Jun 2026 17:23:50 +0800 From: Luka Bai To: Harry Yoo Cc: "Vlastimil Babka (SUSE)" , linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kairui Song , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Rik van Riel , Jann Horn , Johannes Weiner , linux-kernel@vger.kernel.org, Luka Bai Subject: Re: [PATCH 2/5] mm/khugepaged: use slab cache instead of normal kmalloc Message-ID: References: <20260531-thp_collapse_hint-v1-0-e7f8c2035621@tencent.com> <20260531-thp_collapse_hint-v1-2-e7f8c2035621@tencent.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Proofpoint-GUID: vWiI5DfDlKo9d_pTiAL8bLxbN4XYVEVa X-Authority-Info-Out: v=2.4 cv=ZKPaWH7b c=1 sm=1 tr=0 ts=6a2a7eaf cx=c_apl:c_pps:t_out a=YrL12D//S6tul8v/L+6tKg==:117 a=YrL12D//S6tul8v/L+6tKg==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=x7bEGLp0ZPQA:10 a=UaoJkeuwEpQA:10 a=VkNPw1HP01LnGYTKEx00:22 a=GvQkQWPkAAAA:8 a=kZerjp_4y9AqR4350q8A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjExMDA5MyBTYWx0ZWRfXz55/QVcYLGVo fjA+rDUkbTg/5s3fdTTH1xBnati0BBf1LZoUEsKBt14uXCMw/vrzGlxIByX69y/kGDVdoEZgPJT utU+tR0kWEZE4aA4l9ufhHpnO/tM+iRLcylnUlBI0Q2IBuvhWJeSMbe7izIRfOaZtXQ5bHyowUW rJiBq7POXSC0z8dutLIKQ/1wfyYABlBD4xqBSRSTbTC+Ktc17/B8uza24ZZaF7RaK16i2rzzdgE XuiD3OzV4+7oPuwzuJa5IaptGSvM2TGLwcsysIODMQ1VroSu4B1QIl2z1JRHN+YcMPo6/K3ce48 IBNc7yUyXr4ZEYmxKHuOgR0Sbb7RKlZ9Zq5nxLztbd7z97wYhF1qf4DtoVWe2k= X-Proofpoint-ORIG-GUID: vWiI5DfDlKo9d_pTiAL8bLxbN4XYVEVa 在 Thu, Jun 11, 2026 at 01:35:46PM +0900，Harry Yoo 写道： Hi Harry, Thanks for the review. > > > On 6/11/26 12:16 PM, Luka Bai wrote: > > 在 Tue, Jun 09, 2026 at 12:26:18PM +0200，Vlastimil Babka (SUSE) 写道： > >> On 5/31/26 06:23, Luka Bai wrote: > >>> From: Luka Bai > >>> > >>> We added a kmem slab cached called collapse_hint_cache for > >>> khugepaged collapse hint, to improve the performance in allocation > >>> and freeing for the hint structs. > >>> > >>> Signed-off-by: Luka Bai > >> > >> Khugepaged isn't exactly a hotpath? Adding own cache comes with memory > >> overhead, so this doesn't seem like a sufficient reason to do that. > >> > > Hi Vlastimil, > > > > Thanks for the review :). > > > > Yeah Khugepaged is not a hotpath. But in my implementation we will allocate > > those khugepaged collapse hint structs in other paths like walk_mm() and > > lru_gen_look_around(), which may be called more frequently under memory > > pressure. I'm a little afraid that directly using kmalloc may compromise > > the performance of reclaimation... What do you think? Thanks. :) > > What makes you think using kmalloc compromises the performance under > memory pressure? > Sorry, I didn't do a comparison test for slab_cache against kmalloc to be honest so this conclusion may be not very rigorous :). I just analyzed from the implementation. Since khugepaged collapse hint is just a "best-effort" implementation so I don't want it to influence other more important procedures and that's why I wanted to use the fastest way for it. 1. Using individual slab_cache can help it use its own locks and slab caches from what I see. So maybe we can improve performance by reducing the lock contention? And I found that mm_slot used by khugepaged is also using its own slab_cache. My hint struct should be allocated much more frequently than mm_slot during mglru scanning. So that's why I said that "using kmalloc for khugepaged hint struct may compromise the performance compared to using slab_cache", still, that's just a guess. :) 2. We can also save the fraction since kmalloc only has caches for sizes in a power of 2 if I remember it correctly, while khugepaged collapse hint struct has a size of 48 bytes. So maybe using a individual slab cache could be helpful to the fraction. Of course this reason is not as important as the first one. I didn't realize using individual slab cache can have that much negative influence :) Maybe I should actually do a comparison test for these two machanisms. Thanks. > > Best regards, > > Luka > > -- > Cheers, > Harry / Hyeonggon Best regards, Luka