From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89436C636D6 for ; Fri, 17 Feb 2023 18:26:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 064D66B0071; Fri, 17 Feb 2023 13:26:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 014846B0072; Fri, 17 Feb 2023 13:26:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1EAF6B0073; Fri, 17 Feb 2023 13:26:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CFBC06B0071 for ; Fri, 17 Feb 2023 13:26:21 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 970A0C0661 for ; Fri, 17 Feb 2023 18:26:21 +0000 (UTC) X-FDA: 80477613762.08.E2723B5 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf14.hostedemail.com (Postfix) with ESMTP id A3179100002 for ; Fri, 17 Feb 2023 18:26:19 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=xWPOsc5V; spf=pass (imf14.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676658380; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=b03GfOT4dkuf8arvwGMY+h7JsXZlR+KDPY8uVhKZfJ4=; b=XKPXHM07m6pEsTdYRgEatm0O2li8vAQ8yvgfWAZ9DxPoYByGg+H9x1PMQKTcUBOxPyRg+N Y+oZ3obab8bQO/l4VBlsrm9Q5oELkZ6GF4AnMq4rgJeUXIbqVOxFGcOcNgZuPxZqlP5Tda 95ITdqKoOVqa4R5Cr13CHHPQETB796I= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=xWPOsc5V; spf=pass (imf14.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676658380; a=rsa-sha256; cv=none; b=8AgBR+tSxRzTkCfU1iTpNNDBTHL8N1PxbVatW/6MaVJ100fywl3XtYGChIVpVp5zsFjqCX S8gx44f6vMgnGc77ZJ2gsjxLGZYMK0CeSe/fAbeDLmBOyJiZblWqRvWTaT9hMFel9F8Chq gr8D8LiVPbDcQ90l3Vca0ErDc4VdrcM= Date: Fri, 17 Feb 2023 10:26:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1676658376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b03GfOT4dkuf8arvwGMY+h7JsXZlR+KDPY8uVhKZfJ4=; b=xWPOsc5VYy1gGTb9sWGQQOnvZT4z3cLJyptPALTEUOIyzo1o/UcEIIR15mb202Psn6SljQ vLiT1BNs7vnef1jh57hqSVJWLxOR6v4r6k4BVt1Lvyq48vE9VEIAM90aWEebCyBvAN7VEz eXCg0ksgNq9WlC+5EWGs7OAvMOp0uns= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Linux regressions mailing list Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt , Johannes Weiner , Michal Hocko , Muchun Song , Andrew Morton , Waiman Long , Sven Luther Subject: Re: [PATCH RFC] ipc/mqueue: introduce msg cache Message-ID: References: <20221220184813.1908318-1-roman.gushchin@linux.dev> <7a3e0cb1-54f0-73b2-d9e5-db4d28836bfc@leemhuis.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a3e0cb1-54f0-73b2-d9e5-db4d28836bfc@leemhuis.info> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A3179100002 X-Stat-Signature: e3watbauj4j9hkgwykzkeursgmm1uex5 X-HE-Tag: 1676658379-728937 X-HE-Meta: U2FsdGVkX1/0dqB9i45fMlpSSl0c+UnVcmaDmS/UljIrv7NA+14q0osy7ytg2KDmg4EyMJycw3wjKqvutWILdh95aWUEmTYM7JrYVpoiukN+hSya1tjvcMJB+Zl2vowZCerpfdGzC93Z0O2OYRDd8iHekZlmAzYd2qJtbOQZ+5YOhTL+yqbAMCZhGoyWsInfJTI+6U7JdtoE8o5B+gZ02hU8Jmg0EUqS45W9eMbwFfSDNzw2w6rN0M7XLoHEaQc6c42oepM+2gLJDVV0j3/UUXtDe5ZUzyTOqxbg1i7Vn2yhflujR1N6kA2oO7tP5buxsiF9HiVgn+0FoOvJFfPfCY7zbD4BlSexOjTRTqN0JzDvNmIj0fZT5Wt0on3RoCdOGIk5DkJcdbXpua/OkyczY5URLOATP/YRJq/s4mm0TUZ8W7gs1haYiybYbIXJ+dVxAYY6Kuw05EEl5oc75JS1pUT9BFW5kDRjqqCx0gd/6GR6PvDwCO5Qxml0TF+pfM3hBuwFIFeQX2Fpy8kTur5Wbvac5/4DXQQDTiiuPsMM/ndcM6FvaZJL0LZR9sBEjO56LQit4BHScCQAFl3QoOgXe0ndTymBKP69s/D+XLR7JHS4hJ7Z4mH4sQWrNAPX+MfY1E7wA5+6PRQkk8vp7mHaoXNxQdf9EQgvVgLdmBDz04B0i2ExJaRYSz2cTEwzSGB63tImCn5khP7z+twkWIMB+3c8c8p3D0qNR/iup9qlYSBultnY4e0uOCT13GHrfd5sPG4q5xg9yE3jcgIBC1qlVvvp/7tyRhZUBDmGOEnLC5j6UBOWKIHUVSKnbw+3z4nLXKoRF//60u7oTeLPOgmfHkYNnXkI43mou4IHomb8e2WCqBmrBYXYegbKp4dtiZHweqcORNcaJlPPKeuP3jpWgyS4+qJ9E7/I4mz0zIorMcFPmssBtSpSkwry79ia1Uqbi06zgYyecho37nX87qz wVwr1qUZ pjIT6TB++XgFVLjp3OnD5exUlvtZ0ryjJnNRiQ4G0O5i1iLf85Ecgybg62mXWxuoNRQ2CxrcppcAiC0/t9uodrnkx+wWq08pkv1lYUvbnAMCiHDWIvOiuDPNLI6UTyIoJPl927A3YUgLGhkU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 16, 2023 at 01:29:59PM +0100, Linux regression tracking (Thorsten Leemhuis) wrote: > Hi, this is your Linux kernel regression tracker. > > On 20.12.22 19:48, Roman Gushchin wrote: > > Sven Luther reported a regression in the posix message queues > > performance caused by switching to the per-object tracking of > > slab objects introduced by patch series ending with the > > commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all > > allocations"). > > Quick inquiry: what happened to below patch? It was supposed to fix a > performance regression reported here: Hi Thorsten! I wouldn't call it simple a regression, things a bit more complicated: it was a switch to a different approach with different trade-offs, which IMO make more sense for the majority of real-world workloads. In two words: individual kernel memory allocations became somewhat slower (but still fast), but we've saved 40%+ of slab memory on typical systems and reduced the memory fragmentation. The regression reported by Sven and my "fix" are related to one very specific case: posix message queues. To my knowledge they are not widely used for anything that performance-sensitive, so it's quite a niche use case. My "fix" was also hand-crafted for the benchmark provided by Sven, so it might not work for a more generic case. And I don't think it can be easily generalized without adding cpu or memory overhead. On the other hand I'm working on improving the speed of kernel memory allocations in general (I posted early versions some weeks ago). Hopefully it will mitigate the problem for Sven as well, so we won't need these message queue-specific hacks. Thanks!