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 EEFC1C3DA6D for ; Tue, 20 May 2025 17:44:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A6966B0085; Tue, 20 May 2025 13:44:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 457536B0088; Tue, 20 May 2025 13:44:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36D756B0089; Tue, 20 May 2025 13:44:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 160A76B0085 for ; Tue, 20 May 2025 13:44:57 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4B302160C66 for ; Tue, 20 May 2025 17:44:56 +0000 (UTC) X-FDA: 83464011792.24.055A40C Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf19.hostedemail.com (Postfix) with ESMTP id 482A41A000E for ; Tue, 20 May 2025 17:44:54 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FyT44P2b; spf=pass (imf19.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747763094; 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=a+243UgmCf5IbLKB0ZKHityJf0HqvyRfIfY7BV2Z36s=; b=Jh6d15eezy7XPYjJa9RFt+pV/P8cYPFbvwYl1DDEURM0BTOc4crqnBxcpodcTd1fomRie4 goxQQxhKq1nCpeiVFKyhtuK7lbnc0mCz98mDaQSeNcanbDmzoSv/UpTUcgso70gQkaYfVk 9YtqEbhR7WlVLCeVDMQg4fpIZKMi19k= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FyT44P2b; spf=pass (imf19.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747763094; a=rsa-sha256; cv=none; b=ScrSKD5126/XfXc0dTgarE/qxuD8RH1N8urvptU3NyJ15HIAnpdQC3xTpuhLPFR/+nkvZR kAWkgU/tfD+wZSSrNXKq1H2zFgDa7RVQLW0TYLJ49Kc7bWOAMzX6SfIPjeNUEz1ajjh3L2 aK7PlqOQ+jy7tyikx2yDvNy8JBagbwg= Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-551fc6d4a76so1504279e87.0 for ; Tue, 20 May 2025 10:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747763092; x=1748367892; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=a+243UgmCf5IbLKB0ZKHityJf0HqvyRfIfY7BV2Z36s=; b=FyT44P2bpMS6bQ8Dey4Urn8eK1DnhtDK0D0HGv7tL9mQclbpxq1oAKJW5qNP6NLD+n 3V+qXtR0oJM2X6Jb3Mg4gyo5XjYXwnC/e3vxm6XK6sMHI0V/nbUwZO+6Sz7+zml52vWq mbV7Jjkwug3vlMrcrxqeHEre5O1aualfjxoODwLrCVyzhr5o/MtoDKqWlKeBD/GbmSGH QtlTU3T8B3098rHkkBg4/DcMhQV4fXsroV322Oj2nCAiEQY8FHZ6J2rLDsRGQM/ZJ1+/ m5yXFdBL6FOzxQnZDS6YgqA5TyM+KX+J7+ZgOrZc2H5Hr9YwFrvKKvTYgGoiYvrKImpN ifoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747763092; x=1748367892; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a+243UgmCf5IbLKB0ZKHityJf0HqvyRfIfY7BV2Z36s=; b=gOa2lWhpcIkp29VASBGGk6Axw6Pz+OxOuqJdwkeD/2XQdcdyLKn56Y5UQd69740gPJ wXrGuqzd0blzZbFMCcgZl51fXYzx6laPHC37VyxLjjsZUU0FeLt/FuDrmz29FcElw0P+ IIMCHjO6ZcxAhl5yhgKuLFcxA6CtrhU4wU256t04MY7mYPxwm6L+UBj5W0yZxA6kmgNN 48KnjW2jRWn1fbEeZA2Lw0U9IXKrFcmrJT9n7wex/h9/rPfUoBdk8FvWSWXIA5OJbzTr XY1rl2X4MLiMmWyclEjnfBPydXD9dZdHTImz8O8uQPsjLVmLR9wrgBmPGItWwoYxmSHP aH9w== X-Forwarded-Encrypted: i=1; AJvYcCWcb+vMMxeXSd1iyt6VF4bGfGPgmsoC1vFBa1HGhWDS7GsU9EVgK2E0nQFGoiT+KNDyIrdCL/9QCg==@kvack.org X-Gm-Message-State: AOJu0Yz+9jePHQ/H6RijUXmvguee/s7I9eEZcf043QDDAlLXSRDbKsrL +j8LnPH/dOMWqkWCqMtdRX3xJJxYhTFMObYkz4kKtOYMUjxDN5JMJJ+p X-Gm-Gg: ASbGnctbvZ4stVPGIiB3Y+LFOyXfAO6dKiWfxx5LkI9cL71/brvVpvtATvqu/tzHaD6 fanwBOXxMCjTU3jjSmtOaBbqm5EpZy+kOYROyaFPJpCMk+TAbxx0+3aXg34ySD2zcbT7U7LuH+b epwiBwzUnP4kcQH17WYwYprjhRHN8zJj/AqCMgwtWHewveBjIdwjdvo2KxNVY4mQWD3+tIFjqNw 4sIoSHqANIzL5Sse/6/WIEgMhJXn88TuX7+dhbooIjhYhNcvKL19VRj7Lw+6OA6B+GmbS+XRoSX m3E3gd0OzUvm3AyKmnIfyLgpqqzTR4N7MMCv+MwmpocxdWqK47HB/6Bl2wo4wjM/Gsidso5XF/v /LKc= X-Google-Smtp-Source: AGHT+IHHRvZzdql7ekTEH3LaIAy+GxrgL1+bw83RRKPr3GlWv1t7UN97GndnrNTraxLkRHK49olT/A== X-Received: by 2002:a05:6512:628e:b0:550:e453:f054 with SMTP id 2adb3069b0e04-550e97ce246mr5893036e87.28.1747763092039; Tue, 20 May 2025 10:44:52 -0700 (PDT) Received: from pc636 (host-95-193-69-199.mobileonline.telia.com. [95.193.69.199]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-550e703ca85sm2458225e87.217.2025.05.20.10.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 May 2025 10:44:51 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 20 May 2025 19:44:49 +0200 To: Kent Overstreet Cc: Shakeel Butt , Usama Arif , Andrew Morton , surenb@google.com, hannes@cmpxchg.org, vlad.wing@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH 1/2] mm: slub: allocate slab object extensions non-contiguously Message-ID: References: <20250520122547.1317050-1-usamaarif642@gmail.com> <3divtzm4iapcxwbzxlmfmg3gus75n3rqh43vkjnog456jm2k34@f3rpzvcfk3p6> <6d015d91-e74c-48b3-8bc3-480980a74f9b@gmail.com> <22oihuvcrh5sg3urocw6wbop2v5yni7zinuhywbz7glsee4yoa@gzi5v5fcggdl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 482A41A000E X-Rspamd-Server: rspam09 X-Stat-Signature: 8r5d4zc3mry63ykuzrmffegy68g3gs4n X-HE-Tag: 1747763093-660548 X-HE-Meta: U2FsdGVkX1/ce5wAjBr5sHI3WC6eetyl88oSfWCjPOBxDBp3dW7mhzp8SLxs7/tB4XtaMXE0Neb8/+hDxQ9bS+hRMumQSmxi4PFq4PND9Hyr+Dw0dALtoT95k62mWsG41+Qvsc+A2elapfzx1rzROA1BTxENuB80E7MBru9zK9boeCWf8CqXQYHWe34Wft4bd+psGCDHSOf5KWlJ9/qptey/H07iHvbWoBRITUYLEnY0o/rBbX30uVME3a+fh4exDc0d2Nc6YTSjNm2lYO/lgKNoCTodXYX8gmgE1S+VJPCYdUv4k79dlLLqUuRTcM+ZIkPSQU8D42HgGDrYFDDGfmYqUmyuz/Y6E3KERaFpIi64lb9HW5Wdr01H6K+Daw5o9Vl+b8UO29KdyIGKeB7+XrSeX5Kp3v4390F2FtAVS95LbYni0V7YlcPL1ib8H9Dy4W57JNjXw3gzggpageM5Q8moRF5YcuZXm1gvFFWNxUlOeiE0ozlnaRDB9BUYrZw8RMZSp74/NGY4OspjIGOLbiAbRj/n75L0KLOvvIe3xs7U2+2tldtgDmQTDFA0Wy7/MNUcC4Pka60/tf+L4NjdAykLr7XgTsQ00wAvHmpS8vr5uZUZJT7J/wLSys4d8Uk3oBUsAig21ppf3C2eKyJyjLpgMMhy4u/XGXeK9QRuAfeCO8/gUfrQ6z1y49Q2xLtvWQfn2TjuVRJa2YdAgo/JQwAp2GaOF2bruwGpIXBRNOZm9/Gc6SvVRJDZ62I9kiDIgkrHiXRTV+A90rSOg0UhHpke/8c4lsIJ7pmJJW8BssQHp88KWa0/18qmWVlBbqxLDkVqpMNNXgFUfrg7rAKQlQ1mBL9WItAtFIiXnJDa3Vcv1wfbyuyBmEI2LgFf9JRDbD/U5kvGuDWGq2ZeGCS9rpYSK1Hs8ZpkJfUKG9gpg1f7yDnzZvh12d8OZjMtFMFiL0VBHVDrnKk/t70dI1Z D5h/qxJW XHNKj23f6/HansfiM8tdqnqmL2BwxJvsfizJjxtUVFv5tTR8qD0ZBxm6H3t/kzN9pg43MhjM4a2FDZwNrAeST1jshsBRaBwaXBbCFmjrV7cI08wP2LO+faHPGpDKvVdZRmoQIHLMt6xBmF5d+ST2uLadw3D8Q0vm2j7w5NbHwuO2CtPlldW38a3ykNA6PA925e+Lkb8lXDnanzMjKdq3TGgqFl3i2WsUoPmEoGcj55Y3jPVWsRY9UrroNaJeRNWODFIDDyPiSvimw81/oeKot4fJaLB6M5YM/+rTkFTOjJruCim4SI+pJsTd3Ev44rY1r9bTth3ojoxCvXXslm5Q+jRaDridZJ19rw7UPJn6Yl0WDl7oR1kdop5TvxLJGYakxBSNiJd0im0uJkC3e/aVIcU3Hsynm0t0ubBuIiumdt9qnleegPidlA2aP5UhGhM0UIl8E71IwNqSsRaArNwiriFxI0XRKtuwiJlgirxHvDqVlVGdxCs9HX/av80ZTo6v8jr4G 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: List-Subscribe: List-Unsubscribe: On Tue, May 20, 2025 at 10:28:06AM -0400, Kent Overstreet wrote: > On Tue, May 20, 2025 at 07:24:40AM -0700, Shakeel Butt wrote: > > On Tue, May 20, 2025 at 10:01:27AM -0400, Kent Overstreet wrote: > > > On Tue, May 20, 2025 at 02:46:14PM +0100, Usama Arif wrote: > > > > > > > > > > > > On 20/05/2025 14:44, Kent Overstreet wrote: > > > > > On Tue, May 20, 2025 at 01:25:46PM +0100, Usama Arif wrote: > > > > >> When memory allocation profiling is running on memory bound services, > > > > >> allocations greater than order 0 for slab object extensions can fail, > > > > >> for e.g. zs_handle zswap slab which will be 512 objsperslab x 16 bytes > > > > >> per slabobj_ext (order 1 allocation). Use kvcalloc to improve chances > > > > >> of the allocation being successful. > > > > >> > > > > >> Signed-off-by: Usama Arif > > > > >> Reported-by: Vlad Poenaru > > > > >> Closes: https://lore.kernel.org/all/17fab2d6-5a74-4573-bcc3-b75951508f0a@gmail.com/ > > > > >> --- > > > > >> mm/slub.c | 2 +- > > > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > >> > > > > >> diff --git a/mm/slub.c b/mm/slub.c > > > > >> index dc9e729e1d26..bf43c403ead2 100644 > > > > >> --- a/mm/slub.c > > > > >> +++ b/mm/slub.c > > > > >> @@ -1989,7 +1989,7 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s, > > > > >> gfp &= ~OBJCGS_CLEAR_MASK; > > > > >> /* Prevent recursive extension vector allocation */ > > > > >> gfp |= __GFP_NO_OBJ_EXT; > > > > >> - vec = kcalloc_node(objects, sizeof(struct slabobj_ext), gfp, > > > > >> + vec = kvcalloc_node(objects, sizeof(struct slabobj_ext), gfp, > > > > >> slab_nid(slab)); > > > > > > > > > > And what's the latency going to be on a vmalloc() allocation when we're > > > > > low on memory? > > > > > > > > Would it not be better to get the allocation slighly slower than to not get > > > > it at all? > > > > > > Our behaviour when thrashing sucks, we don't want to do anything to make > > > that worse. > > > > > > There's also the fact that vmalloc doesn't correctly respect gfp flags, > > > so until that gets fixed this doesn't work at all. > > > > Which gfp flags vmalloc is not respecting today? > > GFP_NOWAIT. > > As to why, you'd better ask Michal Hocko... > It is mainly due to pte_alloc_one_kernel(), it uses the GFP_KERNEL #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO) to get a new pte entry. I think we can fix it. For example if we populate some region and allocate there for NOWAIT. But there are of course can be other hidden problems. -- Uladzislau Rezki