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 B7748C3ABDD for ; Tue, 20 May 2025 17:18:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C45D6B0089; Tue, 20 May 2025 13:18:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29C2C6B008A; Tue, 20 May 2025 13:18:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18ADF6B0092; Tue, 20 May 2025 13:18:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EFBD26B0089 for ; Tue, 20 May 2025 13:18:22 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 64DED160B28 for ; Tue, 20 May 2025 17:18:22 +0000 (UTC) X-FDA: 83463944844.20.3634E61 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf01.hostedemail.com (Postfix) with ESMTP id 3FED740005 for ; Tue, 20 May 2025 17:18:20 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=LOqnjtK7; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf01.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.196 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747761500; a=rsa-sha256; cv=none; b=s3pt7G49PslXLTygUR+jtTCVyMArcqm3HLG3RcweJJGtGhflZTI2MvO/kEjG04b6SstvlD 8X9KHAQ7b+kg1+s42OK7tocW3dLCJCACFGpipaDoyZVBBL4v3QS1N3/B6Yg+hBTesuWfrl gwRNz0sN/KvPARr4XYi+pFquTYRu+HQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=LOqnjtK7; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf01.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.196 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747761500; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=b8g+Wzhfz5B8szoWnxmhLEqR559LReTGMLzbHkIJgXM=; b=oRcdKTWpGF5pHgP0S0ziqEx+M1Nycqz/ee+eMq0oxieFPfF4je8guMNVGYw/V7HZ4Rq8M8 FvatAUXO8g3Y1HXx7YQbMlKYkKgskX78amgKhqkhv3KvVGp9dSY975o7ISqq7SSkAn+Ul3 l5scg4V3XMVmXkhf1Ol2MF5kLPXQ2gU= Received: by mail-qt1-f196.google.com with SMTP id d75a77b69052e-476af5479feso64235501cf.2 for ; Tue, 20 May 2025 10:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1747761499; x=1748366299; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=b8g+Wzhfz5B8szoWnxmhLEqR559LReTGMLzbHkIJgXM=; b=LOqnjtK7f0nVSZJW4e5gxxeGrhGG6PU8IzVrKbACJ0TwjryAwZw+zLyV2tt11KbtTl qxeiBngcc10HBy4NCBvTY86rBIm9Z9bqxQWxzJO2meAvR7uQWXZ0UHY7BD857Kcl8Ar6 /TjwY+CSlvUnenWQhJigN5KTIQhrQ9OB4hXboeXaOxV3ki0hFO6vSNSqnYriU8actOap tR6j6ifgmLb74oDAydaEI9iFRE3Qc1bEucg6w/rdFx6tf22UpG66UqJ/Q3su4JyHOjkK esCyMaoOxwtRJx5WxNlY/FQwzc87NhPhlnl5IpeLsygNzGXxs7N+YpE5LXXsorKF2jFI 9hwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747761499; x=1748366299; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b8g+Wzhfz5B8szoWnxmhLEqR559LReTGMLzbHkIJgXM=; b=f6RogWKfMDHQGJLcDWfAErp0/JxR7rRJYCDAKQUf0yGTHh3LE5B4gbkozoSyP3pZjw +oxf5ViwpcSb8eJk+JOSS4jgxN//MlhBbS5vHD5RqZVD58aM735gKuX/1Wi/SlK7wkHm LDDE7Bv3EFInuUHg987xpxt7mkDtGeExBGXs9l725GizbSug0/kdlOx1xnM50ry7cUEn BIgGlEYIhkfUcsQTkgEr2mTHXT90A87MchkV/KIyG6bpktEm/4oItS+6QO8KUchNwvs6 0E6dmWuWTqFMTP/YiIfuV9Eb0YfZEVEDcfU+YrY7pGbxEFBnAg+wXhlwXcwUAFQZshew 7nfA== X-Forwarded-Encrypted: i=1; AJvYcCU+FYLYqjbu/EnVJ9dURmNowoahiuzDtpnF32tI7v3w+kPHdsFKVP4mhl0FZ8Kb2LfpOp74MizKlA==@kvack.org X-Gm-Message-State: AOJu0YyQsaqhzX67wVwosiLgRi9hmO5uL6+3TIADoEYDoB+4IhF+K4YY h+eDTmiQYeADwE+o8K2XJO99TW1VdsAOO5s3xyFND1QBzevw3NW1Jm6+jYtAlYzwWKY= X-Gm-Gg: ASbGncv5Gcze4c0MfWeGnnNVwILPGdT6p0EJkiYYOAAB1to3s1bfjI9oTjcH3s4E2IL cr8CoWyGqwRutCjdeYeFACxAtRlDFkjMTLwTogz1v89FXzqqdhioKfC2K7SpsbAMLxX6Bxgdy2y d6xUUBVnR1HjPoAum93lvWUg1XmZiCTIxJU3Lty0L3Md1u6eVXYxcT/Eaj90s5twKr6Qnt123Ef byfyi4QJ/judxtXlR3oePrv2HyNmfiySse4n4/QHH0Grk87TJwQjb0cPseacD1lbzBuFlGXqWIY Ekd2HL8pGWfxyBIYjBzTTwN7ijDUYZ892fdErQA9GTV5b9L99Q== X-Google-Smtp-Source: AGHT+IF3vxJLFoWuPMLOAda2AzUWAGYkc1HWDEx6oFnY0D+0fW2Y+u+FWJ1vkeSFfmD0B6aa9ewRRQ== X-Received: by 2002:a05:622a:1e0b:b0:476:7eca:57e7 with SMTP id d75a77b69052e-494b07dcd9emr285134001cf.26.1747761498978; Tue, 20 May 2025 10:18:18 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:365a:60ff:fe62:ff29]) by smtp.gmail.com with UTF8SMTPSA id d75a77b69052e-494ae3f922csm73377711cf.26.2025.05.20.10.18.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 May 2025 10:18:18 -0700 (PDT) Date: Tue, 20 May 2025 13:18:14 -0400 From: Johannes Weiner To: Suren Baghdasaryan Cc: Usama Arif , Kent Overstreet , Andrew Morton , shakeel.butt@linux.dev, 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: <20250520171814.GC773385@cmpxchg.org> References: <20250520122547.1317050-1-usamaarif642@gmail.com> <3divtzm4iapcxwbzxlmfmg3gus75n3rqh43vkjnog456jm2k34@f3rpzvcfk3p6> <6d015d91-e74c-48b3-8bc3-480980a74f9b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3FED740005 X-Rspam-User: X-Stat-Signature: ar9whza53xcn9mysbxdh8xwhh16y45j8 X-HE-Tag: 1747761500-284822 X-HE-Meta: U2FsdGVkX1+GdroMT0WUwNA5lfCoe+ec+jiHmE0qQgoDrupYKGQ5zpGOgcQJKkDRjUQwDKhWlTzobCMTS4uG07LzvzH88vZ/HSeIbj0z+Z7ulQJEJcZcGbEsGVRRdTFrrXCNa3pmvP26OYXTY9O3nDefKvtWS18BoAjzwKklNhuV6zqBGOMzugu1MVpGBSQgmejZUWtv1XV+t0bkpyi9rSINK1/y5fxPxZ0gxsIl/AiHrObMLaJaUtfl+ZQuIUO+R8TN5z548iwWkhnoYkeikwtbI/2FGtG61hV1LDbOG+nNpaNThxnK/mHr3Efsa2VatzZghXh8QdS2Rj3LkQNQCYJWqKPERLWQAvjBIBbt/VwFXbbVtjRwGlxDDWaEJo6J7uMfDE5tJ7hU5lJ4xMgbgsGr5KF5cZI2wJ4ojesflGwDi7sWK4wmx/NR9q/ER+kkdGVJeV1Mwn7ujALzpn9VN3g3vq57hht7IsGC6y944e6sOfVIJtONIKvHE5z6s+xJT8KNjFZQlJ1f3Dm+Li/x7AOB/hJn5BggRb5lIuaWwzlmm307kS1t73ieSz2z+JReMT+EBz9nAhv4iKJ4Tpw8nWUnDVmxhNcACqt6eOS29WMwpVLMHEG+kwf5HRyUfpurjYSudweuEN/POAjvLEED4p3mTu4xxvH6f7yIm1DJ+hZu6hWFpgIQX5hMw6PmVROqDRoelLm233kWEsQ5elrMk5RVVk31h/gonVlWE35p3NuO7FE2nrcDHHJqYlTKi9MSO0fNLm+7v0zShYngAHSODraLF+urefwz3PrbEelkBieHXi+wn4JWtNveP8XhPIZpABUwYmnIJCDT/AqZzo7/+eewhisPq2YTvUwN8/FITopCTqYjGxdo+hlDNFJyLYCs8aYwB9OxkQJk2XsYVR39vl/6NX/62BIHQDqCPHPSsZSMz2R96pD4tPkK98WIj4/lILnsM6vDVGnvE7MjiQo opoeKQD+ Xr04CJLqCQ0X1D1hiZHckB633Z50BP1VjtFB2rtsZlj3acT8NyduoR38UtpGnMaEu58+GTM/nIBPTzuB5G4eQgiAED+NDJlS0w6NbnU21Tsax6scdNMonQiMsY8cMZ522v0h5/s0v7zXXp9PFyHz9cgNPRg7u2bj+tcE2byLSLU2ltpaxLq7IA/gIQFXx+x+DqaGMHQg+0lZqmt3eZ2K15uubJo29XFqEH/mnV4vn/JrkBQ9x0G+5uHuaWtnyy9DKAxIIh0HytKRme5sh9bMEMA43KV3nZMO8k6cmEJArk4l+bKHTq5rZoHjviJydPbhZMjU8ihjGGQDZCOTNknSAR0AU4RjaYP3QgOE0unIUmU66oA6pPueqvbqfI/EwNLwK4mlVuEegyqdpVBobzJC68D64Ax0z9TlINbDIxbPbPA1kuQ3x1CkedPfxg5aRXCGSb9d8DnPQ3a1bvRv+++owIcZzWbK4lzTv419gSp7tLsckngn3KV9Bl+xwX2Ec9CdP2IHGgTSgLRkNo3UYCRFxYBTxuu5LxWrZABMKFbI9dIZmLn27FdrTLpdY+RPqVHzkCdKpROrLmvF2+FdMWhWCmF7/BQ== 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 08:20:38AM -0700, Suren Baghdasaryan wrote: > On Tue, May 20, 2025 at 7:13 AM Usama Arif wrote: > > > > > > > > On 20/05/2025 14:46, 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? > > > > Also a majority of them are less than 1 page. kvmalloc of less than 1 page > > falls back to kmalloc. So vmalloc will only be on those greater than 1 page > > size, which are in the minority (for e.g. zs_handle, request_sock_subflow_v6, > > request_sock_subflow_v4...). > > Not just the majority. For all of these kvmalloc allocations kmalloc > will be tried first and vmalloc will be used only if the former > failed: https://elixir.bootlin.com/linux/v6.14.7/source/mm/util.c#L665 > That's why I think this should not regress normal case when slab has > enough space to satisfy the allocation. Alexei raised a good point offline that having slab enter vmalloc messes with the whole slab re-entrancy and nmi safety he has been pursuing for bpf/probing. Add that to the other concerns around vmalloc, and I think we should just drop that part. IMO, the more important takeaway is that we accept that this allocation is optimistic, and can and does fail in practice, even if the slab allocation itself succeeded. So it probably makes sense to 1) ax the warning entirely - since it's not indicative of a bug. And 2) accept that the numbers can have a fudge factor in practice, and mark line items in the report correspondingly when they do.