linux-kernel - Re: Fast path efficiency (Re: [rfc][patch] dynamic data structure switching)

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Sep 2007 09:14:28 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Oleg Verych <olecom@...wer.upol.cz>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Paul McKenney <paulmck@...ibm.com>
Subject: Re: Fast path efficiency (Re: [rfc][patch] dynamic data structure switching)

On Thu, Sep 06, 2007 at 01:05:40AM +0200, Oleg Verych wrote:
> * Sun, 2 Sep 2007 20:36:19 +0200
> >
> 
> I see, that in many places all pre-checks are done in negative form
> with resulting return or jump out. In this case, if function was called,
> what likely() path is?
> 
> > +static void resize_pid_hash(void)
> > +{
> > +	unsigned int old_shift, new_shift;
> > +
> > +	if (system_state != SYSTEM_RUNNING)
> > +		return;
> > +
> > +	old_shift = cur_pid_hash->shift;
> > +	new_shift = ilog2(nr_pids * 2 - 1);
> > +	if (new_shift == old_shift)
> > +		return;
> > +
> > +	if (!mutex_trylock(&dyn_pidhash.resize_mutex))
> > +		return;
> 
> that one or this?
> 
> ==
> 	if (system_state == SYSTEM_RUNNING) {
> 		old_shift = cur_pid_hash->shift;
> 		new_shift = ilog2(nr_pids * 2 - 1);
> 		if (new_shift != old_shift && mutex_trylock(&dyn_pidhash.resize_mutex)) {
> ==
> 		> +	old_shift = cur_pid_hash->shift;
> 		> +	new_shift = ilog2(nr_pids * 2 - 1);
> 
> /* hope this repetition is needed by design */
> 
> 		...
> 		
> 		> +	mutex_unlock(&dyn_pidhash.resize_mutex);
> 		}
> 
> What is more efficient in general sense,
> as opposed to s,3,2,1,0 Optimized?

I'm not too sure, but I'd guess that most of the time the compiler will
be able to figure out they are the same.

resize_pid_hash() fortunately isn't a fastpath anyway -- it calls
dyn_data_replace which ends up calling synchronize_rcu() 3 times,
each of which is likely to take a long time!

-
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/