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 AF927C3DA6D for ; Tue, 20 May 2025 17:26:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51DB66B0088; Tue, 20 May 2025 13:26:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F4F36B0089; Tue, 20 May 2025 13:26:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 432B16B008A; Tue, 20 May 2025 13:26:01 -0400 (EDT) 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 23F0E6B0088 for ; Tue, 20 May 2025 13:26:01 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BAF37E5BD3 for ; Tue, 20 May 2025 17:26:00 +0000 (UTC) X-FDA: 83463964080.21.4B6C2F6 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) by imf22.hostedemail.com (Postfix) with ESMTP id C9BB9C0004 for ; Tue, 20 May 2025 17:25:58 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=CKXs4fQZ; spf=pass (imf22.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=kent.overstreet@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=1747761959; 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=yaQEyTq9qu2VZtURmi8lqNHxZL4f6GMQAiHJcnTGDtU=; b=74BWYTpR45VjwIZKRl55fSjJptWE0DiQu6gMc0ULtpU+CoKqYvCSg63HUDdTN9mXYFQ9ls m1rN2MckSyreSCr2WacDz1nTvN0z2HGTxGJVx1D+RmieNGCk/bVq8k8K2JKltFg/MpBf98 92uiO0VTmMAwgFoHvSON1NjpB3wiq8g= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=CKXs4fQZ; spf=pass (imf22.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747761959; a=rsa-sha256; cv=none; b=a5gzRRw28Ww76qUhrjn+fvO3WcSOMWAjuh8utTkTdSCEjn4D6WmIJsrW34yfTJ1ILmdIap U0fIncG0BpjbYUVRVMVK1QonrRgrwwvwYbTYgZ8IlD1BgzA39OyIOJ+2x+Dl5tNOfjzehY JJ2/vcdXWE1/m78LwG1BPepQcdeacmc= Date: Tue, 20 May 2025 13:25:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747761956; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yaQEyTq9qu2VZtURmi8lqNHxZL4f6GMQAiHJcnTGDtU=; b=CKXs4fQZkMwRpIdaLdlJvTkZR8MLDYAck0rJ2OU+RBzeY7oqjcbrs7BNds+nptgiEX05U7 6Pzt2R49GURFGzscpqWF42qJsyuPXcccC2bl0Vg8C7fh92tL+S42Itu2gBHmZntNkbhpv0 FUguGHJ/oMYkdUSaeGgSquu44RwZaMM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan Cc: Usama Arif , Andrew Morton , hannes@cmpxchg.org, 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: 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-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: C9BB9C0004 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ciueey9m8qrznrnkqczxtuu9wpszz93e X-HE-Tag: 1747761958-139665 X-HE-Meta: U2FsdGVkX1//rtcUis4cUBpiV0B72mF8JIDUr3QUw/GLN47jan/4WxaSzOZQuHKGh8AGgWQV16F4NUZEkRfNPSXH3Gx97Y/ddIS7GiC6cqCeoOM99v2coMjAo0SRWbmpQd6PJ8WrJN4tX5NONufaHB+TxEyA+Yrx8VLmm5BulmMlhm61PP9awEc+vHl6o7dd/k4Hmi9VN7+UN5n5SNjja5HO9l/LeosV0R2d/8YeYGrx7+ryQgHXzYYyKZG9LkSr6VtOuONnVgtjtJYU0/xG49TwtkPDEo0cnf+kUjH5q3QqnyRv+FoBwi5oJqQjSnCYHWpuTipzLMudtbioKDDixHWRbvj6IGHjJkttXLjNa/E5Ck1IXtOGbPasYlnQHi6uDDeEAYhFZf1ucZm4k4YKjSxZ57631KasmyWUpvWpGfn9xZP1GuvDGWOPt7Pwr31aJsjKw5/WJn0Are3NxCyn2wZYfKBMGS1VQ6esuEIIYifA/w4YBKc9TYx7kXuBkON3WPDlCGrgh7x7eulRRXCzjJgXhJPU9nycczLUBwrecLRJjNIJyrB3iWczohClmcfDur6RCaYMVb/hculIaBm+YTwBzFJb50pm9z/WO37oH3/X8t5U2IRBkXV68LReenkDaTBXt+Bm5HSXHgO8FTFjWv27MeaxywghlA4KG6X/jhf360izgrGrDJr9ZSntuhO3EP0FUPbiI1bJif6duV188vRGVRv3WSEX4su/grascFb2ceD1AatkgG0jMk3ET/xdcLQoGkS3MjaKm83IhJF/Eh6FOd6c7rHiF9mIiWvbkBxWHcbqM1mculre19fLKYfwoekkAbfcJyeBaja1zy0wbSnp6L4fk3MU1oUeHuczp6kGXmT1tkX+eyaD7kghaF5hP2Tr0F2VXUh1j5iWH9gRbhxbe+5xaIWfzkIBh3hv0VJsorEtrkoxg1uQvRXjFrdKZGQIQmUD1tgTIATkddb IeFoWk2u N4GYWoTOgOukGnr2blI6/dCQlrtO3cnliy9C8i83Ko+NwfAbTejPpUXlHKKKVCAJJsRB3Kf4A11HTTUvxAVJ22d77lIJp9E0CEIIs2nhCpes0A5KL6HeM1uKmXxrZcGu7eS+LyWbnAfWkUNo1/uaou7h3bjhtGthjO9lA7HLvbT64++hQHdVAWtjhucL4jjoHLPnwf2q9X//zB1ee01iMwZBS11r+sF0/3d4fuMGyW8T+RldPQWvtfUrv29iYwjyBCt45Wa973NLQoUf+bSNqUME2GZJTZVwR45ZPVVsHROL71P8I4GIKViGwDg== 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:20:23AM -0700, Suren Baghdasaryan wrote: > On Tue, May 20, 2025 at 9:41 AM Kent Overstreet > wrote: > I see your point. One case we would want to use vmalloc is if the > allocation is sizable (multiple pages), so failing it does not mean > critical memory pressure level yet. I don't think today's extension > vectors would be large enough to span multiple pages. That would > require a rather large obj_per_slab and in most cases I think this > change would not affect current behavior, the allocations will be > smaller than PAGE_SIZE and kvmalloc will fail anyway. > I guess the question is whether we want to fail if allocation size is > higher than PAGE_SIZE but less than PAGE_ALLOC_COSTLY_ORDER. Failing > that I think is reasonable and I don't think any extension vector will > be large enough to reach PAGE_ALLOC_COSTLY_ORDER. So, I'm ok with > dropping this part of the patchset. Johannes raisess more pertinent points, so I think vmalloc allocation is out. If it turns out that extension vector allocation failures do cause real problems (not for memory allocation profiling, but maybe someone is depending on memcg being precise), I think it would acceptable to dip into reserves for them, since they're a small fraction of the slabs themselves. With the caveat that we'd need to look at how the reserves are sized, to make sure we're not running them empty and causing new problems elsewhere. But just failing the allocation should probably be the default approach here.