Re: [GIT PULL] Hole puch vs page cache filling races fixes for 5.14-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 1, 2021 at 9:19 AM Jan Kara <jack@xxxxxxx> wrote:
>
> That being said I don't expect the optimization to matter too much
> because in do_read_fault() we first call do_fault_around() which will
> exactly map pages that are already in cache and uptodate

Yeah, I think that ends up saving the situation.

> So do you think the optimization is still worth it despite
> do_fault_around()?

I suspect it doesn't matter that much for performance as you say due
to any filesystem that cares about performance having the "map_pages"
function pointing to filemap_map_pages, but I reacted to it just from
looking at the patch, and it just seems conceptually wrong. Taking the
lock in a situation where it's not actually needed will just cause
problems later when somebody decides that the lock protects something
else entirely.

             Linus



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux