Received-SPF: pass (google.com: domain of linux-kernel+bounces-143324-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <e348dfcd-6944-4500-bf84-c58b8c2e657f@oracle.com>
Date: Fri, 12 Apr 2024 13:44:17 -0700
User-Agent: Mozilla Thunderbird
Subject: 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>
 <a8e208fb-7842-4bca-9d2d-3aae21da030c@oracle.com>
 <1207c5d7-8bb7-4574-b811-0cd5f7eaf33d@suse.cz>
Content-Language: en-US
From: Jianfeng Wang <jianfeng.w.wang@oracle.com>
In-Reply-To: <1207c5d7-8bb7-4574-b811-0cd5f7eaf33d@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?L0RmL0xkanM1Y2htRXdBU2hTVVFTcHo4N0lTMXlKYjh2UXQyd1l4ekt5RWIw?=
 =?utf-8?B?dk03anBiRUYvbVpnc1F3eVA5UTlqeTBXN0huYllPK0FwSlJUalE1NDJzTEQ4?=
 =?utf-8?B?WEUrSXJvbmRCOXFjQWQ5Z3VBZjFsdGRTbXFyR3lqeE95aHpKUjV4TFBJcnJ6?=
 =?utf-8?B?Z1hEK1lPV2tZTlFzRmNvbTEyVnNkTmhXUXR6VUhLOU05L1BHOWxlazlpd0Jy?=
 =?utf-8?B?ZnlBV08vKy9RdUQyOHhuUDUvbzU0TVZCSitHMHdYUGpuZUcrMlJpM3NkMjFO?=
 =?utf-8?B?TUNRdHNKdFpDYmVDY1FlSEk3UVQ0SEE3TTUwT2Z4VVlIWkZwdkdwWEM0VzRz?=
 =?utf-8?B?ZC9UKzlMMTAxeGV3N2xqaDhqQ0xqK1lqZjVuOWhReUFwSnNHNGZJWVBkSHFx?=
 =?utf-8?B?Uzd1bzVYQWpwTTB0RmV2WFBzdUcydzUreExoMitvVmY1bFR1NHZ0YWtXUUhw?=
 =?utf-8?B?UFNIUzZMTWlBeXpuSjFqR08ySW5scmNNb1VnVVpaZFRDcFViSlRCRnlRUFZH?=
 =?utf-8?B?NHBPbHREVjhwV1RkbDJkM0V1Vkp1cW5aY0hOeVVtcmRuZHVteEUwZzZOb3ow?=
 =?utf-8?B?ejUzcUZpUG9oQ3pjMkNEK3B3TkdWb1E4dG91UklkdUJzNGgyWmpvb01ML2xt?=
 =?utf-8?B?bzFlZnA2NzRkVmZoTEZjbkllSWZiZnJuV3VmR1VObnBiM3dETTg5QUFIZGFQ?=
 =?utf-8?B?cHdPZmQvWFJRMTRaNlRwMGNEbmVzTDBlZm5FbGtEeW9pTjJoMVhMTGlqU0hi?=
 =?utf-8?B?R29Hblg1SGwwSUMyOVFLdEczVko3SUF2MnNzTmVYME51QXV2RDZLbTNtQnBi?=
 =?utf-8?B?UW8wQUtsVEhFdVFNMkhtVzFCZlcwOVl5V3dzZTVYZ01ZNEprTTZIeE01enFa?=
 =?utf-8?B?MGxUaWxIZ1RwTjRERVltZE9aMUVocGorbWJSNHpIbU1kcitDTzR4LzRGOGdD?=
 =?utf-8?B?MTZxZTRmSks1Y3FwemFiQkF2ell3OXZBbHBEYmhZdTl1WUNMTFgrdWpkbnNp?=
 =?utf-8?B?bDN0RFZ0ei9aU3VWVnJ1T3lmR2JuNGVtaDczZ3pzaTJEbGlOWVYyVnlpL3Nv?=
 =?utf-8?B?VC9yQ2JLWVYrRWFhNkE3VWg1Wm45dHB6ZnpILzlJZlZCNm5KbGxRWTUyTjRY?=
 =?utf-8?B?TTNDQ1piYnhtT3QxWUQ0ODFNVTAreTVzRHlmQ0JuUXZEUkF4YkFMMDdWRFZx?=
 =?utf-8?B?NHZsK09rR2RxU0JLNUsrdnJvQzNmRHk1VUxNZUpjWExzWTRRY2V1c2x2WXJH?=
 =?utf-8?B?SHBtVWE2K2pCSWxsOStZMWZsT3dUYkVKMVp6UVFvTXVETHcwWXZxNTNkMTZC?=
 =?utf-8?B?MXVnVlZtNFhXK2U3WndvUHFrZWJsNE5ycmZZK3AwN3JOUHFOdzErYlRJRS9p?=
 =?utf-8?B?cEZkUnM3TE52OHNYNnNpUmtXWi9xaWJtL2daRGV5QzdvK3dHRWhPcHhla01P?=
 =?utf-8?B?a2lKN0tLUDR2V254bnEzeDY5YmZNR3JSbHdndzVLblBhenBMM0pyQWYzcFZM?=
 =?utf-8?B?U3F4L2NrME5RZGphMEEveFpHdEt3YVhRekZ0MCtLd0h0ZGFHVE95WThaSVJX?=
 =?utf-8?B?RFkvaTVENkxZK2Z4VXNMaG9Oek9PZGxOUVYxeUYyUmh2TkI4Q05KaHh0a2Qr?=
 =?utf-8?B?dEZyT2RuMU5iUlEwK091cHk2WFJRZVJvY3RaQ1l0Rzl0QnRyRSt3SWZNUStw?=
 =?utf-8?B?bUxBTVg3NUJ6QmRtZWRkTVQ0MEUwMjZxdEZHVFpBM2NaUzFMREQvekozb1pK?=
 =?utf-8?B?RlVkejNyczdKbTMrblJwM0FJVDd0Vm93Q1d0b2c5eGY0TWVZNTBFVSt1R2Za?=
 =?utf-8?B?bjBCQWlmVisrVmV0YnJNMGpjU3VUTS9QSWQycG9CREcwakpkZ24rcUhsWjFr?=
 =?utf-8?B?eDg2QlFsMzdFN1FtM2hub3VXdysyVHJMWUc4TXRsQlBFRWZrSFBlTnVmZUlX?=
 =?utf-8?B?OHJJTkpBdERqajc4YzhkU1d5d3JQN3RubmhTMVpYTEppbkk1bG5FSUNPT0xn?=
 =?utf-8?B?MHE2b1NTNk5aR2Z2UkNQYW1iOUo1SDVNdklUVjdxaVpmbmplbXBleGxWOEZq?=
 =?utf-8?B?ZEJWN21nVStsVzVXNGFYK1dCeDh0U0JrTEIwekRuV3BXNDN2dllGT1RKeEV2?=
 =?utf-8?B?UWtmYUsvdjVXcUQ2aTk5Q0l4TXF4aVphbEZvWnpGUGN3SkR0SXZhYm95Mnd2?=
 =?utf-8?B?N1E9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	uOq+Dw5sIKlZYu/rKmvAUWT4Cu6i5dNRESaWhIEdepgddLUhgo1w2f/1ozzS0zy+ox0onsuPKk8tsJNh3p9wlvH18kjrBoaZ7bpDXyfDgVRplWkA4N+SHMudn5CketCPUXcTxS2XNIydN5fhGU83ogsy/M8shxl4CZd405VZQNgBxT8ZCSK1I5RFG/Z5IekZfpngjviaBEiyGHuZFQTDcywzzDyZZQbU3LiKDcOFQrxKlmWGOyh5GA1MJMGt7PMHiaRuMcry67oPcT6np6I2lOdaCpJ0TchkePBMn8HQR7k8g3pY/mD1Unl4r0kRIK14RQkgrHdiEWVmqepzEbEv9400oDn2UsXeRAfokBnP1LKZpzfYv0tVukKXY6/EsnGu//vOCNzgp489c3L1aUedZ2AC41RnYs7WpFpFuU3hau03KjKeCZ6ny56O1NBlnm3s32oCztJAr7eF2X1ARMwfPEL5mo/eY5xDCQDPX1pCcIW/zPgn/5WJk3dt2G9vQtIaXIVRkpf7oWKXBRL09uvJ4/VuYTV9jmH9KP1/T6ye371us9Jq2Y3tPUc5XUPGk7P9T0x8+VOiOBwqBAR8fc9wu8n4OcpNuPjMy5u73cHIy/o=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 639a5492-4636-48ff-e2bf-08dc5b315e48
X-MS-Exchange-CrossTenant-AuthSource: PH7PR10MB6379.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2024 20:44:37.5003
 (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: oXaEC/8V5Wgo4jnoxH8FjrQkv9AsRinGTJUchO8r5k/dDz+W9TrFOhNYid2LrC/C5dP2DKgY1p0M7gFfniMDxnrRiTdnbvzhd/E2DTOhhTI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR10MB7304
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_17,2024-04-09_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 mlxlogscore=999
 bulkscore=0 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000
 definitions=main-2404120149
X-Proofpoint-GUID: _hymhvOvlLqavESBBn32oOiqMkp44G6j
X-Proofpoint-ORIG-GUID: _hymhvOvlLqavESBBn32oOiqMkp44G6j


On 4/12/24 1:20 PM, Vlastimil Babka wrote:
> On 4/12/24 7:29 PM, Jianfeng Wang wrote:
>>
>>
>> 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.
> 
> Could you describe in more detail how do you make dentry cache to grow such
> a large partial slabs list? Thanks.
> 

I utilized the fact that creating a folder will create a new dentry object;
deleting a folder will delete all its sub-folder's dentry objects.

Then, I started to create N folders, while each folder has M empty sub-folders.
Assuming that these operations would consume a large number of dentry
objects in the sequential order. Their slabs were very likely to be full slabs.
After all folders were created, I deleted a subset of the N folders (i.e.,
one out of every two folders). This would create many holes, which turned a
subset of full slabs into partial slabs.