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 3C5F4C19F32 for ; Wed, 5 Mar 2025 19:46:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32928280016; Wed, 5 Mar 2025 14:46:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D8AD28000F; Wed, 5 Mar 2025 14:46:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17ACB280016; Wed, 5 Mar 2025 14:46:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EA24D28000F for ; Wed, 5 Mar 2025 14:46:37 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 485DE5541D for ; Wed, 5 Mar 2025 19:46:40 +0000 (UTC) X-FDA: 83188529760.03.09E0CE9 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) by imf10.hostedemail.com (Postfix) with ESMTP id 1BC53C0010 for ; Wed, 5 Mar 2025 19:46:37 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=pduOX6Bx; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.172 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=1741203998; 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=4DH4yyq1YOxF+bzlMB1SUQ5BPKUaI0NfAtTF6Qw6nZc=; b=xGTuctYwGx2p9Q6bPsafgCRFExz/N/PtKW3gayZYZqgB7jcywVKUEqrc0llrEiGISMROic x0MUloof9Z1OLZIqHPv2GFGK8qdkc/hceRPi8MYs5qRiG0MLFXzrpH9pYl8tsOMDQfXDXQ 5nfQWvFUCuD19HSiDO+cqLMTPGNxxz8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=pduOX6Bx; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.172 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=1741203998; a=rsa-sha256; cv=none; b=pSnxQ0yJR2C10TtlR49e+GRZnvkzHl8voExJz/QXUsjwiwy1szsGlgDM4PtOAsGfHO2der o1KQaUZl0y/r4u3JUUfENPzB26ns6EMW+Tu6qFEjBJ3k/CaN25BQYVJNiQMG+KTJMNkc6k fG0GY3qvQDybc5BwABbCxHScgiTrnqE= Date: Wed, 5 Mar 2025 11:46:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741203996; 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=4DH4yyq1YOxF+bzlMB1SUQ5BPKUaI0NfAtTF6Qw6nZc=; b=pduOX6BxLOXgwIK495HLbYdHh7S7eLiS5RLNSg+GFiJ5ktzOnd+2EV7XpVFLxK8DtrunyT 3mRF9z+j4Qm18W2W2R2kKCUGnGfd1jwH9x5+xfaC78oPzcII5cWLJnpO4ychcWE0LffRpJ zzbSJRGudHMaD2tDSdJH5MLXkddHS1I= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: David Hildenbrand Cc: Matthew Wilcox , SeongJae Park , "Liam R. Howlett" , Andrew Morton , Lorenzo Stoakes , Vlastimil Babka , kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 00/16] mm/madvise: batch tlb flushes for MADV_DONTNEED and MADV_FREE Message-ID: References: <20250305181611.54484-1-sj@kernel.org> <46960f37-0d12-4cfd-a214-1ddae2495665@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46960f37-0d12-4cfd-a214-1ddae2495665@redhat.com> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: k1xr9nd3n44119ppbj3f9kxxmpnz876r X-Rspamd-Queue-Id: 1BC53C0010 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1741203997-606398 X-HE-Meta: U2FsdGVkX18eJ+BfpUHcCxC7XsHZ8dJD4RLXS+YEmhNum5KHbeedc+9buF0GUU9u6JTqb4zvTL2J/X6ixkelJ1ep69UB/IoxoEdm0ZgpBAF2STFyu5SVBY79fS/pHZb4JaG85Wg2wuGDVFBoMKaaWARYEIPN00btyylbtdv/8+LIIQYFWt/9F02XjxM0aB9lgLjeB6UiHZcK0MZFjwtkD7+2E+8sPA1ulGbxdqlFyBRXHPhwseQlcZ/k5K5+/xM+TxA1qt85Vk4sefzmunbOfgj81kSeFwfsf5GuTkfhhIsRzJkK1iwl7WuTO3QsRoItlluoQ25chpzflqNu8iLD/y5ZAnyyeWVJTgml0gESk6VjyZt2U+SL9FnfRz7E/6jWrvXzvQauw1Y/vDSyaAmX8RrpOsBnrOnD0S0sK+78LDEagZHgwVHZLLQ8m1nk1e7E95U6lxqtTwspndUn9o0pdcbVrjknp6VCZz5VVnTfWBusnH7bBL6ioTKc+IJYIzFBZgmhhp6YL54dnlhB+Sl3qqZU/JDrEDMZPtcXGpRDkC6/vgPue02pfy7dd6cWgbj5tNnOBC3efNwemv9wGDuC7DfV9NDhkbqRJ+qL1NP5YhXn9yjvtb2ZBaaLn0sPVQpL10CmfJwqL9gIh9D7USAmCVPEN2zUt2CmaAu2sFIoLM1zaLGLy6mbFnDNwtAYJQXeV0FL4+iB7VdseQch9zmzibeKLiUQImWgwIlzcaTfNTARLppSjHDTCqxKBvF1UdJSle0QO843uP/ktK2PoURNBXGAeSXpSoWn9LnMh7nRRjeeN9If44w5vhB7UhIDBiZwoIN59BiDa0FDp5FrTxMR66nO+VLP4mkS0/EEopQLyWAXjmfTJnrynvMD1t5QbMzl80SGmhPi3apr2gnkI74YImJwNYdTQRinfIZGRXsOoWvERXKYoDP3BfX6+FH8rKn4nXB9WfgW2xpvuIEsRAa 2RWBh5ys 8HU9sQIG07fK19uU+NmQeK1xM8bNPK/kkhrKLoJP2AB5LwqkWe4XKSlaUUAHjh86I5rinhI9PlIb2qIeeL9s5IAnyYlTr88b0bfuYT4gynAS5R3jUnZMRTthZ2HQT4XE5+R3Tt63sPccE5iNNxvwZWeLEF/gp6NX3CGyae5nTtp2xM4+TYKpAOzhg2PlBzOB9XNYA6PTmKeagg7JnA7EuHOnKJmmw9MMLlooOYEXknzIVe3k= 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, Mar 05, 2025 at 08:19:41PM +0100, David Hildenbrand wrote: > On 05.03.25 19:56, Matthew Wilcox wrote: > > On Wed, Mar 05, 2025 at 10:15:55AM -0800, SeongJae Park wrote: > > > For MADV_DONTNEED[_LOCKED] or MADV_FREE madvise requests, tlb flushes > > > can happen for each vma of the given address ranges. Because such tlb > > > flushes are for address ranges of same process, doing those in a batch > > > is more efficient while still being safe. Modify madvise() and > > > process_madvise() entry level code path to do such batched tlb flushes, > > > while the internal unmap logics do only gathering of the tlb entries to > > > flush. > > > > Do real applications actually do madvise requests that span multiple > > VMAs? It just seems weird to me. Like, each vma comes from a separate > > call to mmap [1], so why would it make sense for an application to > > call madvise() across a VMA boundary? > > I had the same question. If this happens in an app, I would assume that a > single MADV_DONTNEED call would usually not span multiples VMAs, and if it > does, not that many (and that often) that we would really care about it. IMHO madvise() is just an add-on and the real motivation behind this series is your next point. > > OTOH, optimizing tlb flushing when using a vectored MADV_DONTNEED version > would make more sense to me. I don't recall if process_madvise() allows for > that already, and if it does, is this series primarily tackling optimizing > that? Yes process_madvise() allows that and that is what SJ has benchmarked and reported in the cover letter. In addition, we are adding process_madvise() support in jemalloc which will land soon.