lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20121130060412.GG4939@ZenIV.linux.org.uk>
Date:	Fri, 30 Nov 2012 06:04:12 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Abhijit Pawar <abhi.c.pawar@...il.com>
Cc:	linux-fsdevel@...r.kernel.org,
	"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org
Subject: Re: [RESEND PATCH] fs/super.c set_anon_super calling optimization

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).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ