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 44C21C4332F for ; Tue, 20 Dec 2022 20:59:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDE978E0003; Tue, 20 Dec 2022 15:59:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8DE38E0001; Tue, 20 Dec 2022 15:59:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A559D8E0003; Tue, 20 Dec 2022 15:59:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 968838E0001 for ; Tue, 20 Dec 2022 15:59:50 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 41FB5140CDD for ; Tue, 20 Dec 2022 20:59:50 +0000 (UTC) X-FDA: 80263901340.17.95A22DD Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf05.hostedemail.com (Postfix) with ESMTP id 62C41100004 for ; Tue, 20 Dec 2022 20:59:47 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=k2tEgNCe; spf=pass (imf05.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=1671569987; 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=Y37zBw2z34AekRtu6QE+ZHXpaydFvXhSYB4OwYr6Iew=; b=Amaqw/blR3BOb6d7y38LRNExfIoQ/Cn91ss2MFM6iyHcdY0bCHipxIISNFo0mXnY7KX44Z 7/srEBQWi5Ztj5HcOITrGYRf7ReXVgKIj0xU9qOrCJlEjw9v0pr0L2ByhY06vnjpDEUPRM iGUB+QhYlR9QsCEc6eOz119uzfRqsaw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=k2tEgNCe; spf=pass (imf05.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=1671569987; a=rsa-sha256; cv=none; b=KQX6vlQ7T904RlpmUtkNs5s8DJzt5MW8Xc8dJtNtzy8ORTIcWZF1SvN2Mrf0m4wne2fPrV nvvds/DOnZ2UgXf2nB/2TcwTUHAiWRWuA7IiWnTSHgCmZaFLhGQ9WZRvxk4xFWzLpsaBoY nJzyJ2Npcm5UWlGCsSfnActtDDSGqDI= Date: Tue, 20 Dec 2022 12:59:40 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1671569984; 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=Y37zBw2z34AekRtu6QE+ZHXpaydFvXhSYB4OwYr6Iew=; b=k2tEgNCeJh1eRpPJ92swxPAVLxAUrukjoi5xvKpU7tyQKrSgio9+6kQaTDBhZn2wjzF03T laGIVhKyL9PhsRhc8uTgtEG+aRnANgJE0Rdz/aGTKAp3GeL8i+VdmfooHGoTAvO8nIPERh X7XL41kR1leDKMbChd4CqsUnhf5Rtvc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Shakeel Butt Cc: Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 62C41100004 X-Stat-Signature: 7fukgew3csm5z8onsa813a3rosx9w55p X-HE-Tag: 1671569987-225728 X-HE-Meta: U2FsdGVkX19WeCuERcZnw7fdKstOhnCT90n12pSbnkbNP1FH3mlJ3Wy1fcyYQkzUXMOKej8KBnrtpKWoUX7xAUTy1JPZxP7Q5vHklUq4BlvfIU6KN0Z3o6HO3PI+8ogHmQmd/m13oc+btz/Xkey9jy5r3atz8qPP6X8bnHRQBDyIGghFqbIWhzoByV4GU7W5Hw89OPOtQx4hWQujs/yE/HDVUPWDuiyjrtlO5wqW1WV1nzktP8ahRF3KmBZbU0j8f5s0Q4r462SwFuP2otQAXPTaa1cmPx3aZ+fO07zmZF0mSo4/s2csaFqMWPCddbEM4mqq1dnNbXILzti7s2T8n2SnO5Cys+ufMVQPIQT6sGzQsu7CuU6hw0uYbuKoBBfHmiUuollxrb4zhciIiUOES7iZ/ikBiboMobZsevT4EZ1WI6uhyGx0D8oQUA1yY7X2qylN6XCy3BK4FjeXrJmZPJKX013KsnPszvW0+HjKuBQJXs7dubgfcZmhhzWuaiquzE8hmARV6UbMxqknfzuvoOOmNXrxOC8rJv7xHSqQGK2TgRx4HerG+Kx/JlfWdABBqLXJrELM8SOkNK7fECAH55tEpxK7ngjfBdSSq1faJRRr0N31NK/4kHtDCrm2uJ2nApRaOSiNqIoP4s0wcmtZBhwpwp2G4mijdxfRXzhml9CjYI9gVJ9SVtZ2RBlRj9qMhRTHFahMkofmM7G2DQ+RGc2HcMwd5EPTO5jwhoMSQhev94xaawg5aYv0ILMZNjlEZPcrCtqgFvixnZ3All98/jlej+ME1H+zLDtRvwgmgzGx8n4gHrD/+DCIf7SJmbo9X6r6ISWRlDgR4x619bHTOjKIEDob8NIbt0m+PduvCgxCmFzzSaCfVg== 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 Tue, Dec 20, 2022 at 11:53:25AM -0800, Shakeel Butt wrote: > +Vlastimil > > On Tue, Dec 20, 2022 at 10:48 AM 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"). > > > > To mitigate the regression cache allocated mqueue messages on a small > > percpu cache instead of releasing and re-allocating them every time. > > > > Seems fine with me but I am wondering what is stopping us to do this > caching in the slab layer for all accounted allocations? Does this > only make sense for specific scenarios/use-cases? It's far from trivial, unfortunately. Here we have an mqueue object to associate a percpu cache with and the hit rate is expected to be high, assuming the mqueue will be used to pass a lot of messages. With a generic slab cache we return to the necessity of managing the per-cgroup x per-slab-cache x per-cpu free list (or some other data structure), which is already far from trivial, based on the previous experience. It can easily lead to a significant memory waste, which will fully compensate all perf wins. So probably we need some heuristics to allocate caches only for really hot slab caches and use some sort of a hash map (keyed by cgroup and slab cache) to access freelists. What I miss to commit more time to this project (aside from not having it), is the lack of real workloads which will noticeably win from this work. Sven provided a good example and benchmark to reproduce the regression, so it was easy to justify the work. Thanks!