From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (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 B42FA4A00 for ; Wed, 25 Sep 2024 00:17:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727223427; cv=none; b=ufffjdkI7au8MwtJQesP02FtyQw4zYekYImeDo0O1vhKnNBJ71kXySdtMOMZNkwTjUus8ad66iLZzu5NOa+h4iWXB8tzAQiWJv0SEj5HZkx1Bdwc3+lRjtqhaloZOl+XHqtvy4hvs/tQb7L/OWfXoDdS6BkEtb7fOmhHKnTD988= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727223427; c=relaxed/simple; bh=5hsxGADZt+3cXhCh9OMkJh0BKnU54ZNs8F09pPAhWtU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R37L0ttAbV1ujfAUN6IJ15unP5UeM72ekQFI608IuxkkGSFHwAUouYe+JJJbnPSz67IG1SWs4dH0je9ihmO3l8CtSgA95Iz52eWwV0wMkjr/I+qMeEDDdgiJ99cYZmaHAV80j1Fje93mnX/pz7HR8L51x2jFFb+heRNwvwulDcw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=ljcXerHw; arc=none smtp.client-ip=115.124.30.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="ljcXerHw" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1727223421; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=60RWb77E7KhGEei6RFLPQQOgUZMvtWt1fiPjkJlwGt8=; b=ljcXerHwkCYzrIrCYjFCIrurhQJ43oqFq12RyiPVbY8+ub8y6WAHM+imWKgoUmvEVmeN9BUl8CmI4wUP6CKrgCmOstqbvd2lmk5jiHSnce17XhfOByKO+pJqpUb/fyxic8oGynwSXzwO2RCSOtBSuoi0KjG+GUq3Xxlc0/BKPEc= Received: from 30.244.91.97(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WFhOIZM_1727223418) by smtp.aliyun-inc.com; Wed, 25 Sep 2024 08:17:00 +0800 Message-ID: Date: Wed, 25 Sep 2024 08:16:57 +0800 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [GIT PULL] Fsnotify changes for 6.12-rc1 To: Linus Torvalds , Jan Kara Cc: Amir Goldstein , linux-fsdevel@vger.kernel.org References: <20240923110348.tbwihs42dxxltabc@quack3> <20240923191322.3jbkvwqzxvopt3kb@quack3> <20240924092757.lev6mwrmhpcoyjtu@quack3> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Linus, On 2024/9/25 00:33, Linus Torvalds wrote: > On Tue, 24 Sept 2024 at 02:28, Jan Kara wrote: >> >> On Mon 23-09-24 12:36:14, Linus Torvalds wrote: >>> >>> Do we really want to call that horrific fsnotify path for the case >>> where we already have the page cached? This is a fairly critical >>> fastpath, and not giving out page cache pages means that now you are >>> literally violating mmap coherency. >>> >>> If the aim is to fill in caches on first access, then if we already >>> have a page cache page, it's by definition not first access any more! >> >> Well, that's what actually should be happening. do_read_fault() will do >> should_fault_around(vmf) -> yes -> do_fault_around() and >> filemap_map_pages() will insert all pages in the page cache into the page >> table page before we even get to filemap_fault() calling our fsnotify >> hooks. > > That's the fault-around code, yes, and it will populate most pages on > many filesystems, but it's still optional. > > Not all filesystems have a 'map_pages' function at all (from a quick > grep at least ceph, erofs, ext2, ocfs2 - although I didn't actually > validate that my quick grep was right). Just side note: I think `generic_file_vm_ops` already prepares this feature, so generic_file_mmap users also have fault around behaviors. Anyway.. Thanks, Gao Xiang