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 D4211C3ABDD for ; Tue, 20 May 2025 18:24:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 230DC6B008A; Tue, 20 May 2025 14:24:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E1596B0093; Tue, 20 May 2025 14:24:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F84D6B0098; Tue, 20 May 2025 14:24:10 -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 E10106B008A for ; Tue, 20 May 2025 14:24:09 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8AB6D1D2C8E for ; Tue, 20 May 2025 18:24:09 +0000 (UTC) X-FDA: 83464110618.16.16923B1 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf13.hostedemail.com (Postfix) with ESMTP id 8362120010 for ; Tue, 20 May 2025 18:24:07 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UwoDWply; spf=pass (imf13.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747765447; a=rsa-sha256; cv=none; b=DmVHurH2BzslC6nPewyxY92A1zbZz3TnrXC+yNwt3naYrepCQLizc4aC0VlaVkGNVHRw/3 amQKqFk5z8ODfzsCRaENqJsvOzste1DSmpWoNnl91eKVC4td+z6Ycao4WBBh+P4B/ScJVy 6A3qASbdYCyggUrJirOOtVOJVwD9sCQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UwoDWply; spf=pass (imf13.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747765447; 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=nffkF+u3gxWSeDAE8Itf37lA75RK6Rf3vh9YRGkMt4g=; b=GXiGmFNBAYdX+wzJCrNT5qbgauUhLJ6vyk+w820X2A42yDsZfBaz2o68mQciPxeGRVGQuG OIE7B791BfiGFfmHBuXSftQleZWipnkEatQdjNnlO3vIKQ+d92Fd5nsOTZ8UAxYdVbbA/X RMswUDRF/rIgQn6WYV2J1sRVHqKznUw= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-acb5ec407b1so1003920766b.1 for ; Tue, 20 May 2025 11:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747765446; x=1748370246; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nffkF+u3gxWSeDAE8Itf37lA75RK6Rf3vh9YRGkMt4g=; b=UwoDWply7vTSGD4+WzQQQV3TbSfnSkJTiY1MkvC2nn/wqqhDAHye0KwK9cjF6XnT5/ X8v7W2yg6yaICUfVQpjnZKiWn5P/F1u7WjKk3YKeLD56JDjHbwqgZGrIfrh0AeppYJkP dr99YRSezPmgeE1JRJpHyijYK79JxUUFTypSGPch7Os3iNvZ3tgy5hzOyHTXhUBV88mJ 051inVWUti6m9WFRH9ZWCjZcKIEZvXINDKb0sQ4Ms4+FZgDIYVAwxuT3Gk6G6s7OF1H6 B2097AfRzWD6q/Jb99pWaFIp6LL2bVNQfUgGI6XHiUDlBVXIcA7sCFV+v8CIu6q9kgVG OrnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747765446; x=1748370246; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nffkF+u3gxWSeDAE8Itf37lA75RK6Rf3vh9YRGkMt4g=; b=oV6GkfJst+HS6/ik13949Jl/MlgT24h8dDHj57oQXyCzzAEHoW/VKlgs+eyWRb/feW wP4lq1l3MDU2giz6FeJ/9bu3pJMf77hN1jQMPdYvoM9wi5Ujoalt5xrO2ZYYKKFFLoyv MDKm+3DgBu/NdLW3wv6qzWPZFpDnkUZI14irgCmnby0YinS+te3sJe61Z2dP4RovGZ4W FxTbq5NxOSWLvDUC3LXxPYlFq/xIWGR00yYCCB2EtRmxMzUpHF61bluxzs0WT+iDXxBV SRJNZpurtYBt1+3tFanYkpjgPdpWUM59aT9reIkLAX61c5QjX89QPWiJFgLZ9GIXS5cq bgMg== X-Forwarded-Encrypted: i=1; AJvYcCUjCOhR6Fv+ChW1U2WZSNpPy8fNHcjbgtnuP10uGTfxqrlau7OV/hl9H51NQ13aa9mIzSBExIYHaA==@kvack.org X-Gm-Message-State: AOJu0YxHAt08EsxyFurzs4Tzlkia4TIWa3oEV7ZC/HX5+3dWb0ZwgRvL bAjIMtKhHkjVWrVJJdl6OMpyqdYZB24rMLLgXqxiAOa1qCuCbWBqP3qC X-Gm-Gg: ASbGncslyRWhUIVOMfW3u8EenfK8JI0ja6WwJCF1Co4ySifkXZo85DeRqhPGA5l7gPE haswcg6H5jfSfodNuKWlyqITQ8H0DoXQVglial2hzSUJlRwfhmsSNON9nhYNphC6jWChFcpWov9 GPjrmekGFFiudus4jZhj70v/I3cO76m+sqVGfhkow+0CFG9Tcz1pask5dPCnG0gvfCUvph94LzD mIttuMnut4eGbCn728pL8RxrlR4uquHUHwyvkhZymrmUxtmamF5viBlbFFppV/d2+fz4XL3RA1t CoeBu7nFzm6O06SLUeiS7mTgFSlfNmEnWN0nvIoqiXPNPuHGA0u9DDrA6myYvPT+BPcHBNRc0Si 68lZ8ZbeTtubI9jMm7abExLGdQWJqpzCiLNE= X-Google-Smtp-Source: AGHT+IFTobyzwp/Ssql6CtGjBJbbB1JEAC6BoxecpIJmcboc9SYnQ2a6Sjk18KiBZWcMeWJN4+yURQ== X-Received: by 2002:a17:907:2d1f:b0:ad2:40ee:5e29 with SMTP id a640c23a62f3a-ad536b56f88mr1563874466b.10.1747765445523; Tue, 20 May 2025 11:24:05 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:1c0a:f3ac:4087:51c8? ([2620:10d:c092:500::7:66a9]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad52d4ca5c5sm764129766b.162.2025.05.20.11.24.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 May 2025 11:24:05 -0700 (PDT) Message-ID: Date: Tue, 20 May 2025 19:24:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/5] add process_madvise() flags to modify behaviour To: Lorenzo Stoakes , David Hildenbrand Cc: Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Arnd Bergmann , Christian Brauner , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, SeongJae Park , Johannes Weiner , Shakeel Butt , Zi Yan References: Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8362120010 X-Stat-Signature: sxef8ukwnzmonn1rtk4qhgxnyc3cb7ie X-HE-Tag: 1747765447-324394 X-HE-Meta: U2FsdGVkX18VcjCg4LWH9jU2OUQ6yq22yDMMJ+f8ltS4lag7gp18ZHVrIsYSDbGA58/6BmcTUz2byhjHTXxryhbKef+BD8DQ9YzuknhLl3f1dQgee04OEeRsglLaua/k7PfRWIAWNaCTeQMQAX7fc4WfMeRpoF4rIfSeLsDgrAwwFnttyCXdnry61xwstjOAcD2kHhJQiq8mIkkyjKTnxEU/NhdmjPIp/vf69/ocdZvURJpytke9nlK2RC2PIZPUVLbRqWbujIT3gBmTLS6E4giY+QU1cKdW4hrVqVgegLVnWXo/lXeWrFg4mMQR6i7okjWGUCfoCcneq9YBbwmKB8KRhLt5Q2jjbB+QoghoJvhuMcZsb/J6oEFA8mEEIevXizzIJZIvBD64ns6pOcX/wN08TpV3OT+qtpB7g7/XhvxUN2G0tNmnH1dozTmgBx0m3/BSbxylMu2qsmyHgadH6UFILLH3MIA8SWTPvxPYM1eZYAsSbZTwk7pVuUarNPE3bffBNQsqXu2Yb2gaiEKPTtmwGdij/aR+TGGiBScyy3k9RqvRs1tobZvFCt6jyHMTka8DIoeAI+iynQDekT891uIWlctLMkgSo0XTwp4kM1A5CXK/uimtAZyH0oaDUPLUNj0t57nbTaztn14uxVgglZQ01z4XIMEu0GC+j/QtD9DoinItfafszfay8stZao+1ySk+oJcS6gUZbfCFvUksNSudUxfR6JMWaKt9CIKM1p4oJCJXVbDl88KGotRIDSIg44+sPoL1KTfNCxJdBMo+obUUEXBqks9buTbBzk/VykxeNyVNLsPB3Aml8N3EN8BMGgqXngcakyWzy4byRjI6Wy5DrlfSkfwManEoGfG3ly+X2WLGyZAdzP8CBf4j5ZD6CJqWZmUf5tH0sEz4ucHZN5Oapk25giLN2s/w93Tl9O0TQPgWfLxKsod0To6ScWn2dMK2NDdSeeAZoK3xwXD uN35FhdZ Awdf07iDsnN6rXPlJCqsOQmC+F4GzbOf6Y11/k9TGF8pKB9n61orC2fGNENUVSYS27Nlwjeq1TFCdGiafVnOREb9u3NnAIpvKlzabn7ZTpzUTAZVP6uHPNTyHf1s+fV7mtgYYkzJ0gg/I+NRKZGB5bR4a9Z2In7moBLQXDon4yHPE4n7q0yGj2iiLqeJEbRmiGv4iX6J5itiZKHkFQH1OCUBW2ef1G4YR5D3e2ss4r8tCjO4gg/FSVWv6dKZRmfH0jjMT+/evu1mHaFIw1H99Ux22KnF5upHeUhLeIoo+xMHpUiAwxfQD6/kiTEDRzs4hd80VK6vv1s/bTZ4jooFHUPZphpq4dbObCZwvaDVGGWAbalKYp5S5l+w0Z8wERRaNkj3HQDYyrAcEAM8WQduoMA0ZvqHDmNmmesoYfzvJju8ZRLSw1Ntze1G5XL1ZgIYjigdLmxhNn587A8X0kn2MWWihfsaqCGMKs91unpomjKAh5Fo9OCj872td7w== 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 20/05/2025 18:47, Lorenzo Stoakes wrote: > On Tue, May 20, 2025 at 05:28:35PM +0200, David Hildenbrand wrote: >> On 19.05.25 22:52, Lorenzo Stoakes wrote: >>> REVIEWERS NOTES: >>> ================ >>> >>> This is a VERY EARLY version of the idea, it's relatively untested, and I'm >>> 'putting it out there' for feedback. Any serious version of this will add a >>> bunch of self-tests to assert correct behaviour and I will more carefully >>> confirm everything's working. >>> >>> This is based on discussion arising from Usama's series [0], SJ's input on >>> the thread around process_madvise() behaviour [1] (and a subsequent >>> response by me [2]) and prior discussion about a new madvise() interface >>> [3]. >>> >>> [0]: https://lore.kernel.org/linux-mm/20250515133519.2779639-1-usamaarif642@gmail.com/ >>> [1]: https://lore.kernel.org/linux-mm/20250517162048.36347-1-sj@kernel.org/ >>> [2]: https://lore.kernel.org/linux-mm/e3ba284c-3cb1-42c1-a0ba-9c59374d0541@lucifer.local/ >>> [3]: https://lore.kernel.org/linux-mm/c390dd7e-0770-4d29-bb0e-f410ff6678e3@lucifer.local/ >>> >>> ================ >>> >>> Currently, we are rather restricted in how madvise() operations >>> proceed. While effort has been put in to expanding what process_madvise() >>> can do (that is - unrestricted application of advice to the local process >>> alongside recent improvements on the efficiency of TLB operations over >>> these batvches), we are still constrained by existing madvise() limitations >>> and default behaviours. >>> >>> This series makes use of the currently unused flags field in >>> process_madvise() to provide more flexiblity. >>> >> >> In general, sounds like an interesting approach. > > Thanks! > > If you agree this is workable, then I'll go ahead and put some more effort > into writing tests etc. on the next respin. > So the prctl and process_madvise patches both are trying to accomplish a similar end goal. Would it make sense to discuss what would be the best way forward before we continue developing the solutions? If we are not at that stage and a clear picture has not formed yet, happy to continue refining the solutions. But just thought I would check. I feel like changing process_madvise which was designed to work on an array of iovec structures to have flags to skip errors and ignore the iovec makes it function similar to a prctl call is not the right approach. IMHO, prctl is a more direct solution to this. I know that Lonenzo doesn't like prctl and wants to unify this in process_madvise. But if in the end, we want to have a THP auto way which is truly transparent, would it not be better to just have this as prctl and not change the madvise structure? Maybe in a few years we wont need any of this, and it will be lost in prctl and madvise wouldn't have changed for this? Again, this is just to have a discussion (and not an aggressive argument :)), and would love to get feedback from everyone in the community. If its too early to have this discussion, its completely fine and we can still keep developing the RFCs :) Thanks! Usama