linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Abhijit Pawar <abhi.c.pawar@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org
Subject: Re: [RESEND PATCH] fs/super.c set_anon_super calling optimization
Date: Fri, 30 Nov 2012 06:04:12 +0000	[thread overview]
Message-ID: <20121130060412.GG4939@ZenIV.linux.org.uk> (raw)
In-Reply-To: <50B846B2.9040700@gmail.com>

On Fri, Nov 30, 2012 at 11:10:02AM +0530, Abhijit Pawar wrote:

> > 	Because we want it to be a valid sget() callback.  I doubt that this
> > optimization is worth doing, though - might even micro-pessimize the things
> > on architectures where all arguments are passed in registers.
> > 
> Al,
> Yes. it will be helpful in registers case.

How so?  Consider something like
static int btrfs_set_super(struct super_block *s, void *data)
{
        int err = set_anon_super(s, data);
        if (!err)
                s->s_fs_info = data;
        return err;
}
Compile it e.g. for alpha.  Or powerpc.  Or amd64, for that matter.
With and without your change.  And compare the resulting assembler.

Hell, if the arguments are passed in register, without your patch
we have the args for set_anon_super() all set just as we enter
btrfs_set_super().  With your patch the second one needs to be zeroed
out...

In any case, that's microoptimization in the best case and on quite a few
architectures it's a pessimization (granted, an equally minor one).

      reply	other threads:[~2012-11-30  6:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+kxV1F5VxBGawhkV=02LcgHNWiKF-H_k6N-d1TEYNeFAScezg@mail.gmail.com>
2012-10-25 11:38 ` [RESEND PATCH] fs/super.c set_anon_super calling optimization Abhijit Pawar
2012-10-26 13:14   ` Carlos Maiolino
2012-10-26 13:40     ` Abhijit Pawar
2012-11-30  4:05     ` Al Viro
2012-11-30  5:40       ` Abhijit Pawar
2012-11-30  6:04         ` Al Viro [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121130060412.GG4939@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=abhi.c.pawar@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).