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 2E94EC54FB3 for ; Thu, 29 May 2025 17:54:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60DDE6B0082; Thu, 29 May 2025 13:54:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E50B6B0083; Thu, 29 May 2025 13:54:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FC496B0085; Thu, 29 May 2025 13:54:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 30D076B0082 for ; Thu, 29 May 2025 13:54:53 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9E372160EDC for ; Thu, 29 May 2025 17:54:52 +0000 (UTC) X-FDA: 83496696024.29.F684AAD Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) by imf05.hostedemail.com (Postfix) with ESMTP id B95CD100005 for ; Thu, 29 May 2025 17:54:50 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=lJS1AqDr; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=shakeel.butt@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=1748541291; 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=pS2FSZ2IbKnKh7XDkalyzQrPqCzDhOSivlmDlIMu2js=; b=hr5xh2fDi4+CNTEAhX1yjxK3zanELqdw1vUVFqOC0ytKWcgPQfwCXLOWer5i+/rOJSyooG Ccz0AdY8hk+FvlBb7U18Zq55m0ajNHbMCY/8MINvJJnZ3PO+bGn8MImkUOaxCcbJa2huOv i3HFmn7EMvnzKcxIB20BvSWAc+/PSwk= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=lJS1AqDr; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748541291; a=rsa-sha256; cv=none; b=IK8dnfVSveVHPVWBlfKHMlFEd9M3IaXCZMp2MQAAYRMQ1srJPJMBBWCr+3pOQzx0RaqZwS qcnFw0rC6zy/Df3TkszzbuLZpgpq+tvs4MmbUC0Y1wU38ZEuve0FTxvI+hPQpMfyYVgD1U G+WE5quqjtB6YV+wMCWVpV2crRB/jig= Date: Thu, 29 May 2025 10:54:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1748541288; 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=pS2FSZ2IbKnKh7XDkalyzQrPqCzDhOSivlmDlIMu2js=; b=lJS1AqDr42wTTOr9PD8EM9OAg0B5Cqik/XMtq3EZEb3gUBeQKu5BpfeKK+WFgVHf14DGtJ CVx03AxfYYkg+zzK3ct/aZAlRzTnojel4FZzGOiKDf7c79R9hP3N8OEtZQXmleKpSoWeGH FsBbdRisJ5bhu75MsdqKQ70U8lywP68= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Matthew Wilcox Cc: Lorenzo Stoakes , Andrew Morton , "Liam R . Howlett" , David Hildenbrand , Vlastimil Babka , Jann Horn , Arnd Bergmann , Christian Brauner , SeongJae Park , Usama Arif , Mike Rapoport , Johannes Weiner , Barry Song <21cnbao@gmail.com>, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Pedro Falcato Subject: Re: [DISCUSSION] proposed mctl() API Message-ID: References: <85778a76-7dc8-4ea8-8827-acb45f74ee05@lucifer.local> 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-Queue-Id: B95CD100005 X-Rspamd-Server: rspam09 X-Stat-Signature: uuehjkfayo4yi7gd3i6ehm8mme9j773g X-HE-Tag: 1748541290-812871 X-HE-Meta: U2FsdGVkX1+6MI+s8Wv0r3eJeiOAUSXuthm88t3ZGXEBZG7MC2f8kZa1BM3r1CO35C3QW+ayW8Lo26rTzk3fJN4KTWyOyh6Eh6uZwMEDJS7LZjZfL4n0i+inMU2ZXorepEV3O6VE1kkRAmY03km4c3c53BnwdI2nwyvK0UxrXvx4IhB5dJIUTYyqL8xRYuardEt7n+UaWYo/jEIY1wXtjtsfQwCrK43yrmh8u1FCzsg7GRWNPvIev9O0CdX6GaQT99lu6oXUrvvqALvm2GiQYipicnzL+rVM3ZkRLLjvwaB94w0YwVaH5FL/nUY1E4P/cHf1p+kHMYkDFJFP+Gup8GV9kIMc8mgSM4wqHbwv5PwV4n9rsMMD+s5u1QjC/stY6coblk/sXuWYJZyOGBj0BhZGX8rIA7F74K8aTl37wzY03ZBxWrZpzqWFCCVvSv/zUqZEjv3i2XJekm7nufcSfkcMIwLptTTIO1aIgT6RXxGU2x3i8Ui3SCX7wGUrIwxhmFV7lqn0Hk9M8tEDNGU+bmsZDrTDXuZIZj04W4svQ+nSSdgAHNsGEqkDeol/GZ6kAIvjHKKlXmylhrUvYxR/Z2A6NP3f6WDtrlU5YslAXfghRlQSD9eud7j/b+Sl/Re06vF9AdlaOcEbHMxNtWmrheaeznsW+przibLlAHVDdM1UXbbKF1LIGTBqOf0HKyI50DuxgXfBwgXbFugAfB1zkoGjCW2k71zGwQIgWeLuUJgo8CWCj4ZsrIxNix2iSf6GITIJTZnkxr2Po+xy5MkbI3QZW3GGZQjHZTwZEI5h+ZLZhAHOh2gvOno7RsQpBTE4sQjU63qDA/67JsdsAP4hrG+FNdkNzGIpkHq0XD2j1R5a29w+697ZXYyBkVZHMo4MakND+FPbQ/V0g5Mgs/GKN7GpdYzethlI+YFjODdGIB6XfZN81pb4LjOA5gtaibzFkVQb4C9ardNz0o9Qh4P OpDjAs8Y ddo2gAuvgOF0SKypo/vun1blY2Q0yiKgYX5lrIhygLBydYCcrjGXcE5XWvfn9H1spbGb2FQDimomdbw5jhFb2y0jwTyvIBqdeOAjqgQ5dxMEYqhM2nV4gR4kN0/J7Rbv9SbYHzYMB6LUMzM08SpBLe3fylDbPLdalih3zn/D8ugbPOsNEVfAIsUpCHBTisgAblseE51i+iq87UTedt46Uh2v2tw== 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: Hi Willy, On Thu, May 29, 2025 at 04:28:46PM +0100, Matthew Wilcox wrote: > On Thu, May 29, 2025 at 03:43:26PM +0100, Lorenzo Stoakes wrote: > > After discussions in various threads (Usama's series adding a new prctl() > > in [0], and a proposal to adapt process_madvise() to do the same - > > conception in [1] and RFC in [2]), it seems fairly clear that it would make > > sense to explore a dedicated API to explicitly allow for actions which > > affect the virtual address space as a whole. > > > > Also, Barry is implementing a feature (currently under RFC) which could > > additionally make use of this API (see [3]). > > I think the reason that you're having trouble coming up with a good > place to put these ideas is because they are all bad ideas. Do none of > them. Problem solved. > > People should put more effort into allocating THPs automatically and > monitoring where they're helping performance and where they're hurting > performance, Can you please expand on people putting more effort? Is it about workloads or maybe malloc implementations (tcmalloc, jemalloc) being more intelligent in managing their allocations/frees to keep more used memory in hugepage aligned regions? And conveying to kernel which regions they prefer hugepage backed and which they do not? Or something else? > instead of coming up with these baroque reasons to blame > the sysadmin for not having tweaked some magic knob. To me this is not about blaming sysadmin but more about sysadmin wanting more fine grained control on THP allocation policies for different workloads running in a multi-tenant environment.