From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 961DB34FF50 for ; Fri, 21 Nov 2025 14:27:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763735277; cv=none; b=b7crZrsV4eJ681prWseIcwkyQimiLDRsG8kUO3BayLVRqwYsFH6UaPITYfwGmwTJ9sjaI25bqQvCdENxYyN/RpZiIwpG3z0+dIS4dSD7gDpGvtaZmKyLO5AThHlCclVkm4oBOQ/XfDFypm5gCS65jNqGJBrMnGJnmdI5HXfRcR0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763735277; c=relaxed/simple; bh=o6xqFKX+mCdB4EPt9cNb90yxrIRWYYfLvU3SWrITg0Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MBhxdShM4R6c2mIxKvEjNObQL5rxyvscH7is7fnN8OtKfTrMR4m1fcS9+uT4JlLv8H0cphGpPVxFpuAyasXByF6j4S5386GTxkr8reHowUKKF88t7S17yrogS5S/QpLmSqR/MIkJyFuNJxuRGZ+2pb0K4vBkVduK2Y/e2TxEtMA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=FJWmv5tV; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="FJWmv5tV" 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=Ad7rnzLxQ0vJwkKU0eMNiSZLB27i6Dfxa7xXgaavUMQ=; b=FJWmv5tVIrnBnyTdiO4ltNKUxY +ixbn+iOIsLBX2DKsZQwmRZW7qMmU4HKIBjGNBIK2Gw2SuMUl915aMCuzk2+lkelQ4VNfX/Va4iHZ QIHZqMFtUHg3uHHCUSypd2e9uiLzyVfPocUPIU+6XKoYzX8FObjf4+766Jvamv6xeHirZGN2Obu44 Ph4jboO2U5SeK6fPbg2oItZ1EPc3PCR+m+1b2T7WlqHOJyfL4CsdtdVSLQL12RVf10R5+sk7Qm+UF hTS2PsCiBh24JDXeINDtfBMjZWv192CGuhgW08r6w5ZLtARY9/oIfULqwDkfP9MLdEZ7UjRFYQmcC uxB0DowQ==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vMS72-00000002zKD-2Kna; Fri, 21 Nov 2025 14:27:48 +0000 Date: Fri, 21 Nov 2025 14:27:48 +0000 From: Matthew Wilcox To: Jaegeuk Kim Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Christian Brauner Subject: Re: [PATCH] [RFC] mm/fadvise: introduce POSIX_FADV_MLOCK Message-ID: References: <20251121032718.1993528-1-jaegeuk@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Nov 21, 2025 at 04:46:14AM +0000, Jaegeuk Kim wrote: > On 11/21, Matthew Wilcox wrote: > > On Fri, Nov 21, 2025 at 03:27:18AM +0000, Jaegeuk Kim wrote: > > > This patch introduces a new POSIX_FADV_MLOCK which 1) invalidates the range of > > > cached pages, 2) sets the mapping as inaccessible, 3) POSIX_FADV_WILLNEED loads > > > pages directly to the inaccessible mapping. > > > > ... what? > > > > This seems like something which is completely different from mlock(). > > So it needs a different name. > > > > But I don't understand the point of this, whatever it's called. Need > > more information. > > So, the sequence that I'd like to optimize is mmap(MAP_POPULATE) followed > by mlock(). For example, mmap() takes 1 second to load 4GB data, and mlock() > takes 330ms additionally in order to migrate all the pages into inaccessible > map, IIUC. Oh, so the MLOCK part is right, but the inaccessible() part is wrong. Inaccessible is special weird guest_memfd crap that has all kinds of side-effects that you don't want. Wouldn't you get the same effect by calling mlock2(MLOCK_ONFAULT) and then calling readahead() for the desired range?