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 DC4E8C19F32 for ; Wed, 5 Mar 2025 18:56:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C089A280022; Wed, 5 Mar 2025 13:56:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB73228000B; Wed, 5 Mar 2025 13:56:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8208280022; Wed, 5 Mar 2025 13:56:46 -0500 (EST) 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 8A7F228000B for ; Wed, 5 Mar 2025 13:56:46 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F121C14080E for ; Wed, 5 Mar 2025 18:56:46 +0000 (UTC) X-FDA: 83188404012.21.D9EFBDA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 249FB140024 for ; Wed, 5 Mar 2025 18:56:44 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="LH6d/at1"; spf=none (imf23.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=1741201005; 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=gEej6CXH1CV2BnQ31fBeizuHauDDNf4vDJ4qs+EfxyE=; b=4ZEGBdxiY1S4NjBBXml8PlWBvFO/pE2U0Tozqb9jwtY1i/Bb5tTUQapP/gXlOwOYrskNIr RM5tVCIDr6z04K4K74uF1wslFuIPyVqsBRaZFU9EFPBG22SNvDZ4RJpYcIwtB5jzzN+D/s 7tM3+74d6Ty1fZ6tGvHXgU12GJS1D40= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="LH6d/at1"; spf=none (imf23.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=1741201005; a=rsa-sha256; cv=none; b=GHYQGOygvDx7cGFKSHw/QSgfG06dgOgZzYpHhC4AYNK/f3jGRd9BWy3dKOO5vsM+y7GqMt bE9UWbMbwF7o1h5QN6PDJXbdn0HpxDac4R04hUwvBewI/kPND9csScJeMpaO6xctQwMyjJ bHuRPbxN1PjMY5ZviTEMNScRJMCZyv0= 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=gEej6CXH1CV2BnQ31fBeizuHauDDNf4vDJ4qs+EfxyE=; b=LH6d/at14InSRczwufVCXusV4q d+qqSKX36ZVtMaIT3LEUnT+jG5rNrf0j/KV2NJ4cXwVfEkU2ZAk8+hKkB7XPW2B4vnDkoxWe3xfIw sLPShUF1nV4mLXwgxAHVwpdH4ZP76J79AQV8JAJp2v455uDl8oG0+lA/DtfRHz+k6fCFfDblp/JYa 2EzRfACb2rxCkPdZon4UEywvAoEfHa1QnHLji4zlt6X/vH+/DlEE2Xmgj2/oIlT9KoxMWq86xAuwS OJ4Hj5cv9Y2CLQnIrArcH453ZYy2jVUoW9PepF73Q5N0AHRjRdPE2lPFVXUWhkeQzHgat2Szo3RV/ 1qfwHRmA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tptv4-000000062iY-0DXZ; Wed, 05 Mar 2025 18:56:38 +0000 Date: Wed, 5 Mar 2025 18:56:37 +0000 From: Matthew Wilcox To: SeongJae Park Cc: "Liam R. Howlett" , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Shakeel Butt , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250305181611.54484-1-sj@kernel.org> X-Rspam-User: X-Stat-Signature: smexxxk1xa5cfhzgob41e5qj65537abf X-Rspamd-Queue-Id: 249FB140024 X-Rspamd-Server: rspam07 X-HE-Tag: 1741201004-584352 X-HE-Meta: U2FsdGVkX1+TzZp7G4KZqzjkEEtVuz6k1nbIUb18FsOol801havLH0AC3aAEFvqTSVWh8+vAO7Iq7r2j8qqgszL+W57pTwbYa7PtLZ/04Uca3TL6B8Cquj4NIzM5jnsOCLgvNBDPSvMnuTRM0lGm/niEPoM/+gzxpHYY4x9ZFnaSnJv42yq3WlpQAV/XxMALi6QYElitYT2IIoiBADDeToUXqK2hmzjmYFAvgWJ7F9CkZQoYztbSQ91/XNSckiNfNHPuWG4PJAassQmilwqc8EsaoJymYv8Jdm2dF+epdf1aKn68LQtY//tKaf89JIIcKpSSSzyO3dKdyFMUvChh9VublxF4XVg3QsZDlhmMpPN6iLAM6/pVaSF6TPuxKEK2hTbNWqAMB3ZkKIMMfD24ZGPB6phzGzuCLob2NUf/Qx495BH/7Iy28O+KzXBEl40BipbYkPOiD1gUo11P6W1UyBmpb0oC31Z108nNFPyYR2vA8XSP8bHeOq7R3khMsifMWmQEsJNIQYI83ysSDMjuJVPsCNzzGw7a4KF86QrkKL9q+d8JzYgRCfEiseDPTz1V8DDFGrz6/NQBKKLcX0fpEIkDT1+M23JJeDFacTHLsmnNUU9ksZ3fr/so/2gmbdLd4uyCn4asp/e6HrEKS4yADjSVFwI1vT/tqmIIfyW8nGoGk8kc5LATWShs6ai2I65DDkiEXeigiuAg/PS7CYV4jJBvArL/VN8or+MN8GYktm/JTNuYFPXqcgagYaEa15DUEceK1Ng2i41tOYW5GbC//OIobgIMwsjA1yTVzsaMbEjoUBJrhR3NwTs20sCvDRYIE/ETzNLDFdBDZqAPPtF0JwbGNOMU1Mh9tv3lcOqqm66/BnDwCt35foiMAWjMGUPK5Yo4TmgedyqYZoAn8qTShQf/BdZombHJcoJZDj6oGfKvWpjTShs7sggZ8Fuz+nkMI/Sxj8K5wcsbKk1+5Rg BBX79tDA TIKQe35kwzMTgnKRWUPjJEVz/bw5ePXlE6SmM50ytUFzJqDkdKcgrDIZUbdmXNTyJvA1EAnzHLUgjEOtjWEHBG6p9ydGc602RFfs66/F8tDIyA2mIg2f77syOU9h6vO36qJHkzzkHWsLT2QGazQJVd69sSOySGqin/2vLxmDaV2TflEQg1zd756M71d1z3m/KsdoMPgcvFPgyq1K1hZMsWXdkUE1UCQ++BM9obrg4DUPZ4Jvgz/+CtDZViBPzNrl1Y28f/kyHMqvAg9ZloY6S9YuKOw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000928, 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 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? [1] Yes, I know we sometimes merge and/or split VMAs