From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [RFC] speeding up the stat() family of system calls... Date: Mon, 23 Dec 2013 22:00:32 -0800 Message-ID: <0f21a61b-c1e8-439c-85d6-c18903f1e36b@email.android.com> References: <52B8CE99.2050608@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Ingo Molnar , Thomas Gleixner , Al Viro , the arch/x86 maintainers , linux-fsdevel , Linux Kernel Mailing List To: Linus Torvalds Return-path: Received: from terminus.zytor.com ([198.137.202.10]:51576 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750797Ab3LXGA5 (ORCPT ); Tue, 24 Dec 2013 01:00:57 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Right, the __label__ declaration should take care of it. Linus Torvalds wrote: >On Mon, Dec 23, 2013 at 4:00 PM, H. Peter Anvin wrote: >> >> I guess I'm a bit puzzled... the current code should be just fine if >> everything is present, and do we really care about the performance if >we >> actually have an error condition? > >I think we should. You could make it to do something like eighteen >expensive page faults in a row for EFAULT, and that's just disgusting, >when there is no reason to do it. > >But to be honest, the resulting assembly is also easier to read, >because it doesn't have those annoying bogus branch targets all over >in the middle of the code. That was actually my main issue - looking >at the generated fs/stat.s file and not puking ;) > >(it's still hard to read with all the fixup section stuff, but it's >better. And it really does generate better code, so..) > >> I'm a bit concerned about the put_user_fail: label having uniqueness >> problem, which I know some versions of gcc at least get very noisy >over. > >Oh, you're right, I forgot to actually declare the label so that gcc >sees that it's a local one. > >So it needs a > > __label__ put_user_fail; > >in the put_user_try() (and yes, maybe the label name should have >underscores prepended or something, just to make sure it's internal). > >But gcc is perfectly fine with multiple labels in different scopes if >you do that. We already use that in a few places, so this isn't even a >new pattern for us. > > Linus -- Sent from my mobile phone. Please pardon brevity and lack of formatting.