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 D7A02C19F32 for ; Wed, 5 Mar 2025 20:59:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C07CD6B0088; Wed, 5 Mar 2025 15:59:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB8676B0089; Wed, 5 Mar 2025 15:59:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA7F66B008C; Wed, 5 Mar 2025 15:59:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8D8816B0088 for ; Wed, 5 Mar 2025 15:59:40 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C34A1B6A67 for ; Wed, 5 Mar 2025 20:59:42 +0000 (UTC) X-FDA: 83188713804.20.AD0DB60 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf06.hostedemail.com (Postfix) with ESMTP id 3D754180014 for ; Wed, 5 Mar 2025 20:59:41 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Vt9uW2h9; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741208381; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JVTa4WJyJQMpAgWtbAEmNcaVJYbJFy0sdsFXum3dnxQ=; b=MOLzqWdBH9wsfu8OSVNNpCK9su5CqAndCwEtsbp2Ln2IEtPdan1laibdr0t6ER6i1Vbv/b oXSmqVI450MiAIHLRBH3oM0PV3BtUohfF7aRqnBbwPzfQCk/ARSQblNTJ6TwTf1zswNCLB vPc8Me6Sn+hxcvBwzbqMvr8DGPbWcxo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741208381; a=rsa-sha256; cv=none; b=FEChk2D8vnVglhS9Qf2RRIazfgtHbn8mEeME5l/njH/OnjWLK3aE1mg6gWuQbYnBVaRssQ 1wMFeZ1Cv2NE0MAv5BATODC4w89QKyjtCaWNqlVpWQKcfOS8kubaqpMYukSVuaAbTZioSu nI3OITb+tZneILF5na+wMdFVYCkOc5A= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Vt9uW2h9; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id ACCBFA4640C; Wed, 5 Mar 2025 20:54:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2D62C4CED1; Wed, 5 Mar 2025 20:59:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741208380; bh=5tZ/H1V5nC0MfMdCRCS49fAZCgJNQdPJ/C4hIMVP4Tw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Vt9uW2h9x9Ka3Qh8jJio75qlZkxW5hBmnbEnl7MPZ48NbXPkJzm7fBWWyrthyDQwC ELgJ4vDxkoOrGd/CK9CqZ47qyHeGm+v41x1OwBLP51NzsF4ucEbNpYw4LwHMdiFHnM 1tQ9ZyXF7QCmIY2EIVGXW7ac5Voxg7UYG7AIDi/H3eJ98msyQ6U6gUUfPj0IRkBU6h 9T2uMzaPqh0q/U182s+l/CwQTe6XANs8UFoffwb6JinlIDyoZ/cl0s2bHEyg3FLMA6 /JbXzNtFs5BpBSytagD6oeDwfRmf2rLumXjdTBlDOK4rqq/G0y6jYP7exTl6JewA40 3XkAe16A6sGjg== From: SeongJae Park To: David Hildenbrand Cc: SeongJae Park , Shakeel Butt , Matthew Wilcox , "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 Date: Wed, 5 Mar 2025 12:59:38 -0800 Message-Id: <20250305205938.57904-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <7e151e6b-3f81-4e37-b314-c6e9f19c1b82@redhat.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3D754180014 X-Stat-Signature: 43ssy9a17jpx95may1w7w9t5wkuizht1 X-HE-Tag: 1741208381-630725 X-HE-Meta: U2FsdGVkX1/eFt/FYLwOit//0ASp6NSehZ/qYOMjK11AnXm/VS3JUB0VNuLX6DdgxMBzJLB44FdTyOxa+gKQepcHXFZqIK7AtlvoujjEUhsCsuMm25fUdOC202gRfE2IfoO9SZT3gOoP2Ji+cjB/uOULf0WBOv0Rp9etpCixQObsK8W6DvMja4asZ7TmxL30uId38bVu1bR3JAenWDNHcZfYvLKOimtcA2cFP4700H0OXQDzOzryCsDCTtFw/qc6bXs5AjppMtVWTq1HV5Va7TJ71yGbK0JeApQhDZlpI8y8081F+F32rhRamsF4HRx7hz5a/kLhf+Ik6KxFWRjVY8maxCzn+EP/9MJk17UVLx8Ae5w9KhQxyXWq1H+jzTJLF7u6+n09qI+KvGxZOjOGbcdKVE+ecgD1pTc+pxbv+HlVM/EPVRjVi1Ofczkwtf5SWDGHItOpduYtQc6dHOL2IHpDy1ZUfOBgdvyOcmSNsJVbJco3Xhcp9FzYesDjY8db5z3RJCEBbs0jHQl4kC6gY2P8jeqI9XRwzmz72JOxL2Dd6AmdKIODPiKwseX8iSpOVm4JuLsos5xXOU+hTBbnvSistviMEO5eOmuvu+F/TecgyeMr/f4+KWQg1wRGL4/cDpbqSKMm/PUMXJ79IId1EeGdmDH76o1FF0j39ElMvb83kHZNf+00v2hWHmV283tEuObzfe4bJqGSmTY6YF9d1DAgFP3e0ZWf1nRCqmVuvwdew3pJF4gk3q0lr7iDC5YKU1eftqdWKPvGjkS9GyGZA/F4jKvZknNiP0o9+6tINglbG1gGQLt0mblMXNiWcu3G3+6nupmra398Sk8kW9jAe01DorFTthU/b7WIkD8tYuCf7Cu+Nt7gLS+BT+v/hP5uzFChl1cHzY8d3EDptsZ5KLx5fa74iWrOEsin+f2WP6e3Lw9d6WZPyyQkY3cJk6uSLFrrk8xfxnCZbRr6jz8 rMfiiJt0 8UyeBF2ort7h/fxyM7uUX8QuO16IYjYwpFQ6zXeatoAlRs5Xz6IDtOSuVl34VEMzw7mk3LMDZ86NnMrJ6D78ukpIXOxuz4oeQSijgP581b3CLBe0rWlfAhzfQez1OzbIiukxElh9CG5iArzQeRTUyEjznP004lVowtS2CsC/ScimrPeIthL7r7gP8mA+vJKmyxLwtkd5f7cf8quJykN3If6RsTKGtkqLkYC151+TRYDrsM0f4ZmfT0WwM3VFMMXJSG1iXKYG8V2SioSQX1rlRiWF7Sg== 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, 5 Mar 2025 20:49:13 +0100 David Hildenbrand wrote: > On 05.03.25 20:46, Shakeel Butt wrote: > > 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. Shakeel is correct. Thank you for making the early clarification Shakeel. Also sorry for causing confuses. I will make this point clearer on next spin. > > Makes a lot of sense to me! Seems Shakeel already addressed all question so far, but please feel free to raise more question for anything not yet cleared! > > -- > Cheers, > > David / dhildenb Thanks, SJ