Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934595AbbENDxE (ORCPT ); Wed, 13 May 2015 23:53:04 -0400 Received: from mail-ie0-f175.google.com ([209.85.223.175]:36507 "EHLO mail-ie0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933305AbbENDw7 (ORCPT ); Wed, 13 May 2015 23:52:59 -0400 MIME-Version: 1.0 In-Reply-To: <20150514033040.GF7232@ZenIV.linux.org.uk> References: <20150505052205.GS889@ZenIV.linux.org.uk> <20150511180650.GA4147@ZenIV.linux.org.uk> <20150513222533.GA24192@ZenIV.linux.org.uk> <20150514033040.GF7232@ZenIV.linux.org.uk> Date: Wed, 13 May 2015 20:52:59 -0700 X-Google-Sender-Auth: t4iJ9xbr1WgvAlvjdrKt3Sv7r3A Message-ID: Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks From: Linus Torvalds To: Al Viro Cc: Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig , Neil Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2076 Lines: 42 On Wed, May 13, 2015 at 8:30 PM, Al Viro wrote: > > Maybe... I'd like to see the profiles, TBH - especially getxattr() and > access() frequency on various loads. Sure, make(1) and cc(1) really care > about stat() very much, but I wouldn't be surprised if something like > httpd or samba would be hitting getxattr() a lot... So I haven't seen samba profiles in ages, but iirc we have more serious problems than trying to speed up basic filename lookup. At least long long ago, inode semaphore contention was a big deal, largely due to readdir(). And readdir() itself, for that matter - we have no good vfs-level readdir caching, so it all ends up serialized on the inode semaphore, and it all goes all the way into the filesystem to get the readdir data. And at least for ext4, readdir() is slow anyway, because it doesn't use the page cache, it uses that good old buffer cache, because of how ext4 does metadata journaling etc. Having readdir() caching at the VFS layer would likely be a really good thing, but it's hard. It *might* be worth looking at the nfs4 code to see if we could possibly move some of that code into the vfs layer, but the answer is likely "no", or at least "that's incredibly painful". Also, I *think* samba ends up basically doing most of the pathname lookups from its own user-level cache, because of how it needs to avoid symlinks and do the whole crazy case insensitive pathname thing. I have this very dim memory that that's one reason samba ends up being so readdir-intensive. But I might be wrong, it's been many years since I talked to anybody about samba, and I don't run it myself. But yes, that would likely be a very worthy profile target. I suspect we've beaten the "make does lots of stat() calls" horse pretty much to death. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/