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 4CFCFC282DE for ; Mon, 10 Mar 2025 23:27:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C59FD280003; Mon, 10 Mar 2025 19:27:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C093A280001; Mon, 10 Mar 2025 19:27:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD0C7280003; Mon, 10 Mar 2025 19:27:16 -0400 (EDT) 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 908B6280001 for ; Mon, 10 Mar 2025 19:27:16 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 229C21CC3FF for ; Mon, 10 Mar 2025 23:27:18 +0000 (UTC) X-FDA: 83207229756.17.45988A3 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf28.hostedemail.com (Postfix) with ESMTP id 6FC7AC0010 for ; Mon, 10 Mar 2025 23:27:16 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=I+DE4Vt7; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741649236; a=rsa-sha256; cv=none; b=s1g8xE0VTC7SKcvf/A3dQcDL8Q3V02i5jqntRZpeonbWnbnsKE7Y7+oOo+QrC/pRxFLxAt cTY7aMyIM0wmj15dtIpgPBakNfcWDGavr0wAHD9uxdpnwzS4X1EC9I9fa/xCPVcUWrKvmV H39YNb+yYWQRTbSSs6j/wTFz12VP4ls= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=I+DE4Vt7; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf28.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=1741649236; 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=pgTpx8nsTw+Yz1y65nYzDxLEKEgaY/tuTF22BqnWjEo=; b=SK6lZNl2VaAJm8MWN2uP0sLc9VWJX0pSuK46K0hj1d+o8hM11SGU1qIWzX943lMcSSn1Vz Wx3PNr4qhnGDzhbmJoxuDo/TP1U6mIz9kvmTBeaRHhYzI8kS0pyenIfuO/I/aznkVGV4dX GQtFH6tjdLNvBYxcJQU5fDvvOScc8hI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id A800BA464CF; Mon, 10 Mar 2025 23:21:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE9A0C4CEE5; Mon, 10 Mar 2025 23:27:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741649235; bh=47EISXtRQqop9PE2MAv9beMudQ9S+PaE967CyWdD+Ao=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I+DE4Vt7oLaN9yWsBHFZUHJrHSqOrTISWwaoiY+WJC4+0RTkXcMLoS+saITHKWfe8 ANTVwN6/0nemk9HH9gPrm1wkAZ6M8GD5cVcQMFjAUakZanDt1jxN8UMLDef0zTxwUT ms+z7w1w5MDCIYxEDza1aCsqKAbW2Vo6vNVLcb32ZMloaHUOT77Wqp3Ju/9jA1g3nY 8xyVjpC0EC/zmQauK3qYz/xhsrnosth+fqNo9lK/qeC7ECEWONBiKm0b/bJEhcJ/4h +RgPZD55Sw+rU4nEyVMGs0jjwxbRSSgt37HPXREBdyek5rxyMLRP33TJR5POPzSIKp SthCViD//oVVQ== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , "Liam R. Howlett" , David Hildenbrand , Lorenzo Stoakes , Shakeel Butt , Vlastimil Babka , kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/9] mm/madvise: batch tlb flushes for MADV_DONTNEED and MADV_FREE Date: Mon, 10 Mar 2025 16:27:10 -0700 Message-Id: <20250310232710.74733-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250310153921.47d390c637105e3ad6fc49c0@linux-foundation.org> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6FC7AC0010 X-Stat-Signature: t7ptw5azqgkezz1atgookj9gyewns58n X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1741649236-36379 X-HE-Meta: U2FsdGVkX19RBkw7dA0IzUoX/6SdBIEfa9r7pIxxUuvg2nqRgOQ2nPf9rNVbhb3HX8khWhW2OOcTKvbjB5GbqnEWQzJSTbl/YG8JqWgGf1NatrOZQxEaoMfylqdIUqD8twurf4tCCBj2w9xPxfynoi/9eWUGRplrnhdJt13YPjzpObofkYs5bSgn2V2y98RsGf7WKM8ZmQjSTK9q2qavX+4Bu8J69KMPL8UNsctFPwlzbYtHx/CtXX/HciuJTRk/K5+ZvJxDGEA2Mw5/NrffZuzKw0zu1O04GF9E1qUFl6rzRuu34SJJZgtLSFOnkg9Tejj+/wyG7BVtdiZjm/jrTAY5pkgOrBuUjOW0b6HctF0Y1jh8ghw2eB9e2WSnYNChDNyzk5o+ol6xCp2KDIbpMSaMLtWilwK/xC45kh9zvxA4nSrqCrX92AFXWFuYJG78RlY7TCvl1zRccz3KKrco9SyrA/t7JmHmJ1xdfHU82vHyaXazcy8V0nn+Ngv14KNGukomeWkT4V7lE8v9pUcG/kvoNI2YTPdiiD5olh/v2zVbDKMhax7MYQmSsAXhJAygPz0R1UcSEGceDXg2qDWo2QyNjZ7LAdfea2ZWx+Ssz6blL/+1tUdqlDfOKUVQarJJPKHp39FfhcFOMfyuW+nzJXiktWS6goG353H0GMEZLX6CJjEl5d3vxYmkRBE60jS6TjGjwP2GhJey7kbC+fUQdUInfD/rPYyaOwcIpECG6INg2U+Ok+tGgllawAe5AL2RZ9lR6uvPEgGJyTG8aGKgBH4a8cU+3Fw3AmMQX62iXBAue9y1zVLzFgH5yn0fEaKT1MCuwStaL1iyzVcaWdnUVQPNRWNOZJ3yMf8xhSSKW1TMnEMi/YF87PKvSDx75wgiJ4hjPc22OYivzbyPFWkRRR2o2xuG8MiqK2LZuc3di5SzDJnvW48mW3poIQSMVOnwbnX1EHWPriAhs/2g+Mc pHKGS39i rus3fqmFCrbrqKAqypyf4VXoX8HtVk1Wagmk2slVXJGElBT9VIFqim7Q+DT/8fvC6YaZZFmQpDOvpHeddjwstDn5hFDU+1Gi5XUTr7jP5J4hiMfoOPnQ0GSlSArlKJF1kudGYeLldO6r2qu/ciVNFpEOaSaw3I3XH1DEgf8GQK3mwXysrBaMfIVNqOryZ8lA/0uPQIbXzsQr7H2byOWsp24/3UKdS7l4o6bgW04abflMIvwBJlj5ki9bYzG9XmbiPEsmotRf1btUUU+DF7Gv6Z2gUW0hIP+lRBoVAGuf8IyfGo7WTHUNLdzQCPXbeLAGwPN/Z2wtORA0acJK9lk39hQNzpHXHspe+3WOrctGeo5hsB/o= 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 Mon, 10 Mar 2025 15:39:21 -0700 Andrew Morton wrote: > On Mon, 10 Mar 2025 10:23:09 -0700 SeongJae Park wrote: > > > It is unclear if such use case > > is common and the inefficiency is significant. > > Well, we could conduct a survey, > > Can you add some logging to detect when userspace performs such an > madvise() call, then run that kernel on some "typical" machines which > are running "typical" workloads? That should give us a feeling for how > often userspace does this, I agree that could make this patch series more informative. > and hence will help us understand the usefulness > of this patchset. Nevertheless, what this patchset is really trying to optimize is not the madvise() use case, but process_madvise() use. I believe the usage is apparently common, given the vectorization based semantic of process_madvise(). Jemalloc is also adding[1] that kind of use case. And the benefit is clear, given the microbenchmark results that I shared. Also, this patchset shouldn't introduce new regression to madvise(). Hence, I think the survey can be interestign and helpful, but shouldn't be a blocker for this patch series. Coudl you please let me know if I'm missing something and if you still want the survey? [1] https://github.com/jemalloc/jemalloc/pull/2794 Thanks, SJ