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 CDE0EC54FB3 for ; Thu, 29 May 2025 15:28:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F56A6B0082; Thu, 29 May 2025 11:28:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CD0B6B0083; Thu, 29 May 2025 11:28:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 409056B008A; Thu, 29 May 2025 11:28:59 -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 251416B0082 for ; Thu, 29 May 2025 11:28:59 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BB4F7C0A16 for ; Thu, 29 May 2025 15:28:58 +0000 (UTC) X-FDA: 83496328356.27.1453D1E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id F2B9E8000C for ; Thu, 29 May 2025 15:28:56 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="J/Ewa8cH"; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748532537; 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=wJZLfn4ZaURESqFeVB+O8o84gVldERzJFI4UXR2X8FE=; b=Z6F5nE5iyJJUXfMdu8PKSeTMoRQEO/tAmrSOKP3Z9eNqRic7gtVaB/cJb2njrihHlqudE2 O+AcaQmBrHO7vF4JJ3v0nMyq21ui+RQuLF8u2jNjPRictXzh9VuzSl6NhdaFGtQJU28O5g 6A5mQs/YToSLInvbLCHqclrpQJymgXU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="J/Ewa8cH"; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748532537; a=rsa-sha256; cv=none; b=vkhwF1CZavNAL+L1wUBEHf8PKvuO9Bc/uePzNbc8ZUSM5Ab2z1ktT+8UaDCMon4OL4kc1l lHh9BXCa054j+udYOlVfsC+eFwayfqJ0SC/N6RoWXmsJAlmH4PSNEfxNSNkwYGG4OjH/7b A6FLlzF1kAF2vdp1dZozwuiJxOx1eTk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=wJZLfn4ZaURESqFeVB+O8o84gVldERzJFI4UXR2X8FE=; b=J/Ewa8cHz3ojyuCXZY3B0cH6k6 OQytojKqmoTlAVSIwnRF5HkInw/RCdeII+NcbMEIpG9al1SfaLTVy24914xVsA2NZGhu9QdhrirfB GKc/o5bqQRxYrsJ27ed+JgDab6jbhzjmKUJMoko/EuYgVYql+0YAYoHAoR9BFfnInFhK/HUJ9QGEl 0uSfzFmehqagP3urQKcSLIoKLcmDaMEW8Mzui+I5IfonjHsVi6J6JD1+vnqRcw8wZicD54FcurzVx 67ErSZTY9xOMM1GxUJWLVVMxJYf4+CijjF7gZPJfFgJBskMX/F+gZgAz3O3V1cl4AcKPFUuLV2kQz dZWZT7gw==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uKfBW-0000000EsXB-3Mi0; Thu, 29 May 2025 15:28:46 +0000 Date: Thu, 29 May 2025 16:28:46 +0100 From: Matthew Wilcox To: Lorenzo Stoakes Cc: Andrew Morton , Shakeel Butt , "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: <85778a76-7dc8-4ea8-8827-acb45f74ee05@lucifer.local> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: F2B9E8000C X-Stat-Signature: khqnsqhg6w7k3pofuu6ubnhawtodi9r4 X-Rspam-User: X-HE-Tag: 1748532536-536175 X-HE-Meta: U2FsdGVkX1/AuvsWzPF+KfnbYgzMYPx5WR0tF/vyZhi2H/yFCTcLhjHyvGk5OhA44vMWX8Aa13VOh1F/SVaYpvh+HN9BThjSLiGFkadS9eNuXoTg1hNBh0SJfJuqWnNy5guXP7zJ7Khns6kySg1D+CKV4W1Wf2RVVf+Ob4a3byp12yRkzGIfcxPnNLlh152KMJMyThcZ/4UCFapobgWo23UxtVjmXeOJ0rGaUruha1ItsqZu/dt8WSvVasxK/nJdpK24b1QzSSaeG4TRlHDjbhjnSlcMplidK3ACQbnX7dm/goEr988UzNnKojx33yFd2Pedkui/bOm1HE81zPjjZd8MVGnPJ0YsbbRnszG2iiUJrwYFyIv6rEwBk/uJmV+UlI0laRedQVKkGHVFhp0hnzWOgEz87fELNUztS1lBJOBtP7dquZqgn6Z6mqKuLF43GMtEkK6PW1aihp7fMy+m72F4Q6O8Nz58XS8mLyuPZb3YuMwHzSlknsVBMe+7yQ8Pc6IGIiP6CdaXyEKaP1bgVwdavzCWurDKKVqFBradD0EEPm6fCETBwnYCQTml1v+Vfs722WBgwlW9LRK2pgQgiGSzzY3AY7zLemXcQIj4nMV/CCEEAtqutxCHF/3V8jEixq3fwWM8z2oLu3BRtLCObRiqHGZd4jfeOA3aeykephR3JmdwwquH7vqThnmV+WMbExXyGXR2UNNZZdwr6H4TJzSySYn3hQkVpNxruUepuUn1pibae9ydxIYUhVbXcCXqfnRYdaSG+5HQYjzlfzAvsJC6Mnn1TMKdCB0+4uFCfFBO73n68Tgc99G7Sr3O+ErbIlvAnpjebdIPiGvRKKfs+FhCW5+/afTh2uyupETYlPhHdVoMw4+gnexSHWhck4R4nOwCVoF9GY2gWAUI5b5kPLVzArc9YCQVWfV+2PdEHyVQGFRoTwZfHaHtcJbEgcCU7w0kDDr9T51RfaPGO8B j8GqDzrX jQZ3eMmIfOh8IHFM8QzEk/uDtP/rY7PEWxOPR2W1QU/cXKAemA3AbhotUQ92XPbxoeTj3J6DL9pYoyj1tcih57ZEvlactC+KpqkOfQs6Adkyr1ErT44V/ODexRobv5IhiP8bP9vaMD5guDZU20+LQQ9LQqK6ZMqgMs9kBlPs87LaNXJgBRZ9Frf2Y81yOj3ynUT401h9RaUBVxlZEvTUv5UYY6fd91cHbcnsGVeOoInLkyBo= 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 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, instead of coming up with these baroque reasons to blame the sysadmin for not having tweaked some magic knob. Barry's problem is that we're all nervous about possibly regressing performance on some unknown workloads. Just try Barry's proposal, see if anyone actually compains or if we're just afraid of our own shadows.