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 C22A0C3DA41 for ; Wed, 10 Jul 2024 16:44:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 438E46B0099; Wed, 10 Jul 2024 12:44:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E9476B009A; Wed, 10 Jul 2024 12:44:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B1A56B009B; Wed, 10 Jul 2024 12:44:03 -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 0DD9A6B0099 for ; Wed, 10 Jul 2024 12:44:03 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B5F431C01E2 for ; Wed, 10 Jul 2024 16:44:02 +0000 (UTC) X-FDA: 82324415124.27.5B97A41 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf05.hostedemail.com (Postfix) with ESMTP id 1BBFA10001F for ; Wed, 10 Jul 2024 16:43:59 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=S01KkJW2; spf=pass (imf05.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720629809; 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=VeGxfIscTnmCHUgchXQE3ZAheQUYMepuC4Wizh7o3p0=; b=nU8JIK6bjsSSOHg5diH1EbhdUW6cKEqpcCZV0Nf2/uN4Z9bxqovftAzufYWhZzhjKe4teg YjHqxvb2A9NEramKy8Pb/hbBbCXbvxb45PwDo/96NYODxtW7SwB4bxUlnqM8de9T64yY8a eK/Dk0tjafJFoqe7Ma9wdM7vwBGBdYQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720629809; a=rsa-sha256; cv=none; b=dnGCeGFS2MKlZN0uJLA0kpC4XTjrgtQYtPy9kTPSBOLtesQwMucP/RJcDCgZgCsYgUZUCC sioT0/vLPs1vvWhO65CWUwTE4dpPDnTRXaOtpp4L4IwkTK6QjlCZqwswYMYjcfXBUJjV4k s/64OmGtZOE0t2isDK6h9/4xlkGjs9I= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=S01KkJW2; spf=pass (imf05.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1720629838; bh=63ZDLAYd3hfvN/LoaXzrMmGZ70fhQEglFAUDeSTVKY0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=S01KkJW2u696bWqMrfpMRZFjDgSxB2m9Gc8411NkKJ9p7Fjm4ii8+vaoRyiSw2Ibh HeR14koyUBl9qusUeNsu6aSUrXu0pDsekvl5KCA/vj4d4qrpSswiP+jq6czWhvIdRC 0HVltiLuQnVs7I59cFV5XI8qxG656KNbdDJYGqFQ= Received: by gentwo.org (Postfix, from userid 1003) id AF6EB40366; Wed, 10 Jul 2024 09:43:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id AE51D40365; Wed, 10 Jul 2024 09:43:58 -0700 (PDT) Date: Wed, 10 Jul 2024 09:43:58 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Vlastimil Babka cc: "Matthew Wilcox (Oracle)" , Andrew Morton , linux-mm@kvack.org, Johannes Weiner , Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [PATCH v2 2/6] slub: Use alloc_pages_node() in alloc_slab_page() In-Reply-To: Message-ID: References: <20231228085748.1083901-1-willy@infradead.org> <20231228085748.1083901-3-willy@infradead.org> <624cc2ee-9335-31e5-4177-97fe676b6e76@gentwo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Stat-Signature: bronzzx6p5k9dmtaaqwehpk4epdt8pji X-Rspamd-Queue-Id: 1BBFA10001F X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1720629839-719295 X-HE-Meta: U2FsdGVkX199pM3kwX2AqS56uSCRa6a6cri08BtZWYTiVr7jMqj1JzE1dm2U/6spAFH26BV+g8Oq52zS0MdYa6IqGyQkk8f35EswOpHtudh0LQUbQ7o4JkPB/vRa6Sw3OjUtGiW4hDr6tQyl3MSqHkI3r2WzfK2JkBBahUyXpM07kFbBJojHr2HOvgeP34fr7dkYGvJn3AckaV/tl/t4hvPpOerr1HhYlp2Pl8PW4sA0Q5ABkTnOUIgftwst6uNtHSziHUnaPWLCRY53U9XFFysRcNodysyE956FZiIahp+/MN0JTaHFqQE+tCUvHiNBvcK3BApIkkP9Zx34jH0CmKFBcuFmtolqkguoBMFDhGR4/Z/YhhTROam7l3ZA4YAJACTmAmcIhTJxrXtJkIMFSov0Og/doQcx/1Gc9IrO6TLaN5+mHeOX9V2b/tPhrturl9J/JfOoi6jNxjxDt3kPxbc+BeyC0XvpEbUNvY3JAh+SHtbt8rxOaQ9NTaYKSLSxGjnN2kPM1pWW+axc6HvoZDuqlbNrOQqVLpvQhNSva2DmR1iknFVm4MNVVjm1zbNCaVQ0+ziQa/ybTdkIVInmisKG9E4OlfZNDUpVtsMnQjqgAJ3ZC/5p/KOObFDQRVeasD7tckHpVmGq12pudl5a1i6Eg3Z0NEwydzB3OrbrsEnVH3VNBGkSwwG4hiaI0++4kOtrsogbUzWJalG4fanCDpTfnBwFQwwCR4JcwO78/DDVz6yYYamT1JfDjcKYsfwbSzq3v+YlUpr7Sqquf5nbM75Ta0yp05HacHEJWTOxDyF258tgQEyFx9ocZFNHXIzatNo79cqPKTOUZFwetJQsqQfwZT4zwpCl0PVTsdTS8wkw0wkd+3E2Tl1NTqcJTX32IgFrlHLsta95UA3A7G0+l8Yqf2nyBzNtwziZktCB+lPG6B74ZVw8L6GoVeNNaXk+Uyvua9LwwIMTtAETB0u +GE4aBS6 LYQyxo7LXeIMs0ydI9I0FpRVQiBnJIVHWXgCX2UFUecflo6Pwj6nlbQGYScuFgcjiGoo0o9kId9z6rwjOB6Na/0bSL7QCEhPzJEassMTB8aFtIP/LorlW3q2i+odJ4XtJ1RsIXlfuYkGxbm5ejSX36b4TTGtIXvizrUowPKt9qmsRk0fKzUxe8DCrRtSQc13QQ4fjz8AOM1PR9XmlCwo7yvZgFa6vVatCaNxvGw79McwTMaNTD+/wueORGKEH7YTb8skYhpgCJAn5789ZwJnqF3bPtWlbc79u2lVS 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 Wed, 10 Jul 2024, Vlastimil Babka wrote: >> With this patch cgroup restrictions memory policies etc etc no longer work >> in the slab allocator. > > The only difference is memory policy from get_task_policy(), and the rest is > the same, right? There are also the cpuset/cgroup restrictions via the zonelists that are bypassed by removing alloc_pages() > But this only affects new slab page allocation, while getting objects from > existing slabs isn't subject to memory policies, so now it's at least > consistent? Do you have some use case where it matters? Yes this means you cannot redirect kmalloc based kernel metadata allocation when creating f.e. cgroups for another NUMA node. This affects all kernel metadata allocation during syscalls that used to be controllable via numa methods. SLAB implemented memory allocations policies per object. SLUB moved that to implement these policies only when allocating a page frame. If this patch is left in then there wont be any support for memory allocation policies left in the slab allocators. We have some internal patches now that implement memory policies on a per object basis for SLUB here. This is a 10-15% regression on various benchmarks when objects like the scheduler statistics structures are misplaced.