Received-SPF: pass (google.com: domain of linux-kernel+bounces-143124-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <a8e208fb-7842-4bca-9d2d-3aae21da030c@oracle.com>
Date: Fri, 12 Apr 2024 10:29:55 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [External] : Re: [PATCH] slub: limit number of slabs to scan in
 count_partial()
To: Vlastimil Babka <vbabka@suse.cz>,
        "Christoph Lameter (Ampere)" <cl@linux.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, penberg@kernel.org,
        rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
        junxiao.bi@oracle.com
References: <20240411164023.99368-1-jianfeng.w.wang@oracle.com>
 <e0222219-eb2d-5e1e-81e1-548eeb5f73e0@linux.com>
 <38ef26aa-169b-48ad-81ad-8378e7a38f25@suse.cz>
Content-Language: en-US
From: Jianfeng Wang <jianfeng.w.wang@oracle.com>
In-Reply-To: <38ef26aa-169b-48ad-81ad-8378e7a38f25@suse.cz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?R1BGUmFramx2UlZ3RnpCQXhpemZUYVc1dXVWZGNScVNlclFkdERIU2dJK0ZS?=
 =?utf-8?B?a3VZT2wxc1dRYUx0OUREakM2Y2IrSVVmSGx5MkI4ZVFwZkwycmtENld4M1Er?=
 =?utf-8?B?UW1haFp5SHBLWFhZcXZSVGx5Z05WRDVtMEZHK1MybUJyUll1dXQ3N2JjNVhw?=
 =?utf-8?B?c29LZE8za2xlTG9iLzBZRFljM0pTRkpVV3plSjdGMnhzQkFVZ0UybENDUStH?=
 =?utf-8?B?K0ZJSVF2ZjRVTXA2dit2ZFdYNUlMbG1mMWdoQ3I0aTRpSDRXYWlreFB0OWFQ?=
 =?utf-8?B?Y2M1QXpFbnQ0M1lNOU5UT3lkUFArQ0J4N2hwZk9nU0JLcUU0aU96d2NsS0dh?=
 =?utf-8?B?ZGRURVNyL1FNRUl2dGRDZUlWMW5BbGhtS1BWOEUraTdobXhFWGkvSXhhUUt6?=
 =?utf-8?B?QjVwVVpGWW9JaytqbEo4UXMwOGx2RTdVWk5oQkJJZXhPOGRZYzVvb1hCdHp5?=
 =?utf-8?B?ZDhick5kcDFXbVQrcU5RSlF3WUJ2amorclRNU1Jad0d4TUZkVVBhM2R6K1Iv?=
 =?utf-8?B?SEhXdlg1akZXZ0VDcy9IVjNpSGpBak9HTjVFK2F4cC9lcVpzcnhNYzlVUUFG?=
 =?utf-8?B?MjdWUFo1d29XdjdjVGJSQmttWnhzKzRCWGhTMEYrNHBGNVRiU2hRT0xTbFBz?=
 =?utf-8?B?MWs1UHdzQkxWMkluUmViSWdUUjM5RjFBY2VGRGl6Wmk0d0RTVDREMllvSUFj?=
 =?utf-8?B?OGlzUXV6L2lyUzJoQ1FVYmZOOEZWOWtsSkR5Vm9TVFBVMFdsbWp1V1hEMVgr?=
 =?utf-8?B?YnJGM0NKVzVyTFpUT040VnMxRTgza2craUZnVFYyb1Q4UERzSG51SEFwU3pF?=
 =?utf-8?B?RkNPcHpkRzREYldvVzAzRmFjeFlIeUM5QThMbXZlb1FINEhyZUpLMkVBMkNh?=
 =?utf-8?B?QXBxbFhpY21ha0tRWU9xUkdGbFFmLzErQ24yMGJpeElvNHJVdzlvZ0VZNDAy?=
 =?utf-8?B?eW4vek1NcnE4QkV6MHFoUjVCM29zWXo4WUVnU2RkY1p0djczY1RSbjdIS2Mx?=
 =?utf-8?B?blZNaDJhdmxXN3haOTVrc2pyRmFOcjJKaU5OOFNEMFdFRWZjcGVvVlQrTW1r?=
 =?utf-8?B?aTg5ZEg4ektaLzZvNzNPakdpNitVUFRrc09zTTEranFuWFdhRjBRSnE2OStr?=
 =?utf-8?B?OU9nY0NBaWd1RGsvV1RKdm4yYXRpdzUwekZycGt1RmNMcVo1MDloZ2dNaTBB?=
 =?utf-8?B?RmxzNlpQeTNRZjVhVWE1M2d5dG5RZFNGZDV6WEp5M1d2TlF5U0pPcTJOV3Vs?=
 =?utf-8?B?REcxV0t5a0pDMGd1dVdHL0JVOTNMSDhlQStwTjM1S0pVRHltOTZlaFd1cGxP?=
 =?utf-8?B?QmRuUFJxMjZCY3g2bmdUTTlrVVFZcEJBNUFIZ0R5MThDZmxOb0xpMUFRa0Fv?=
 =?utf-8?B?ekpmQ09XRkZLMTMwQVRnMjkvOTc5UmhoZCtiZTU2am1kZWJucGphdi8yMU4y?=
 =?utf-8?B?OHVsUlhHL3IrelJIWUFRZkc4M2pyREdiY0NmN0x2dXFqUjQ2UVpRNkt5b1Zy?=
 =?utf-8?B?andWWG44QWhVVnBQblp5RE1iUEZEL29EQUtyUzZPWUxwcnRPbmdZV21Vajda?=
 =?utf-8?B?MWpHVjEyMWROQXl4eU5WcU91azNEUDRmWTFISG1EWi93NUU0S2hYK2psS0dR?=
 =?utf-8?B?cy9EajhpcCtmeTY2RzFKUXVyVFEvRnFPZDNBZGdtbWRhRjQ3MkRST2JPVnZ4?=
 =?utf-8?B?cE9YMzNLT0tKMS9pNDZCNUtoN2tLZkFmTEZpQVdwN3FoODltMGNFcjRSc2My?=
 =?utf-8?B?aE9iUEdKLzJKRTljR1hiVFlMUmQyK3l3L1djUWtQZlQ3aGYvVWV5b3VkMjFq?=
 =?utf-8?B?M3JkS0lSSVdtNXk3Z2pRVFN1U2p2SXlnbzNVdjZVbGRhWjd5Z3BtcVY2ekQ0?=
 =?utf-8?B?Y2k1aEpEN1hqT1ZQY2xxb3pyUFFHb1BVVkF1QWVUc0Jld2llZ2JhU04xeUhC?=
 =?utf-8?B?UGVWZ2h0d2VwUzdUbGRlUTFIT1VRR1B3MkZOeXBtZUVRZ2k5ZGgvWnNLTUdG?=
 =?utf-8?B?bGRaSVZJcUxzMEtVRVRvaGw4aDBRMVpUMFdGcy9ReHFQaENxek1XbVlmd3J3?=
 =?utf-8?B?bVVyWk5TSG9rTU5wTEhmNXp6dDl5a1B4UmRlK1h2SCt6dWFNTXJjODRrQ0VK?=
 =?utf-8?B?ekx1ekZRUllkZExGS1krQm5BRTNCd2F6UzJvWnUyVW5ycU4xMHBoa2lPZzc4?=
 =?utf-8?B?R2c9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	PTbjX18eXwFgKOzPTk2jK9dBPft8F2HnaVCqpX1Xb1jBWIy5S4SWZJbKqYmOS/S4Z3UICZ4kvtR1506MM9TgklDMycFZCDL2ssPDagVmWqifwT+ySw3MewnuYNQrRJyJDSITCTaRW9tLJ1o7ao8uEpvBGDrcyp9dvMp+WHFF61tyf8msjSfM69CQzv+H2LnIq9DzfNCU5ulE26jR/NYKiqcBR2iP0LgNs0oe3TU9d0iyCZ9JyBxfWCJykPhH3tU3M+FRJWpuSX1hbsLalU1v8+bncg4GuPMATJyRit2nzD+WuFt5zjxqAI0H4c9N18V2dxqiCeun27WHKfyfKWLFWJF1HFUMCFjXGxArtE9mS2AxEgo/qjbWMv5EL6OVOoPCKIzE6j8Uc88aLUJaEG+gCh/2ruf1WsuItUAiTwW9aNgUCBBmyMV2BV51xxqoRd84jKXURgKS4vsd0b70IVZHFBDbSEKhnGffNtAve66S730nNuHIHSkm95QSItIq1B29bVAtv1HX1ePX9Jm2V2/PTObPmj/LRqIpGyJxKqYag7o2VE/Cbc7k0Pc5cxZuhNI8xU0FDYNcmqFTU6SGIYDHD9x+DdeiBe9ei8ltjdYvKJc=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8cbdb4c9-4200-4a64-5d49-08dc5b1639ac
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6379.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2024 17:30:19.7481
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: sATbVJabVnfqSx+6tIv14fS/Np6lPXrgxU3kpIr925ai6R0q3WC7RWjJYTkOYQhsG8J8DBOwe0ulCLHrgfxEy5Cyh3SRlEH91GIiUAC1nCA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB7803
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-04-12_14,2024-04-09_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 adultscore=0
 phishscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000
 definitions=main-2404120128
X-Proofpoint-GUID: q7QF_EM1GWQNRfasCJY8yAWaPoC0rnkH
X-Proofpoint-ORIG-GUID: q7QF_EM1GWQNRfasCJY8yAWaPoC0rnkH


On 4/12/24 12:48 AM, Vlastimil Babka wrote:
> On 4/11/24 7:02 PM, Christoph Lameter (Ampere) wrote:
>> On Thu, 11 Apr 2024, Jianfeng Wang wrote:
>>
>>> So, the fix is to limit the number of slabs to scan in
>>> count_partial(), and output an approximated result if the list is too
>>> long. Default to 10000 which should be enough for most sane cases.
>>
>>
>> That is a creative approach. The problem though is that objects on the 
>> partial lists are kind of sorted. The partial slabs with only a few 
>> objects available are at the start of the list so that allocations cause 
>> them to be removed from the partial list fast. Full slabs do not need to 
>> be tracked on any list.
>>
>> The partial slabs with few objects are put at the end of the partial list 
>> in the hope that the few objects remaining will also be freed which would 
>> allow the freeing of the slab folio.
>>
>> So the object density may be higher at the beginning of the list.
>>
>> kmem_cache_shrink() will explicitly sort the partial lists to put the 
>> partial pages in that order.
>>
>> Can you run some tests showing the difference between the estimation and 
>> the real count?

Yes.
On a server with one NUMA node, I create a case that uses many dentry objects.
For "dentry", the length of partial slabs is slightly above 250000. Then, I
compare my approach of scanning N slabs from the list's head v.s. the original
approach of scanning the full list. I do it by getting both results using
the new and the original count_partial() and printing them in /proc/slabinfo.

N = 10000
my_result = 4741651
org_result = 4744966
diff = (org_result - my_result) / org_result = 0.00069 = 0.069 %

Increasing N further to 25000 will only slight improve the accuracy:
N = 15000 -> diff =  0.02 %
N = 20000 -> diff =  0.01 %
N = 25000 -> diff = -0.017 %

Based on the measurement, I think the difference between the estimation and
the real count is very limited (i.e. less than 0.1% for N = 10000). The
benefit is significant: shorter execution time for get_slabinfo(); no more
soft lockups or crashes caused by count_partial().

> 
> Maybe we could also get a more accurate picture by counting N slabs from the
> head and N from the tail and approximating from both. Also not perfect, but
> could be able to answer the question if the kmem_cache is significantly
> fragmented. Which is probably the only information we can get from the
> slabinfo <active_objs> vs <num_objs>. IIRC the latter is always accurate,
> the former never because of cpu slabs, so we never know how many objects are
> exactly in use. By comparing both we can get an idea of the fragmentation,
> and if this change won't make that estimate significantly worse, it should
> be acceptable.