linux-kernel - Re: [PATCH 0/3] Fix sysrq caused USB performance regressions and leak

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: <20090710103412.70152f8c@lxorguk.ukuu.org.uk>
Date:	Fri, 10 Jul 2009 10:34:12 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Anders Larsen <al@...rsen.net>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Fix sysrq caused USB performance regressions and
 leak

On Fri, 10 Jul 2009 11:07:53 +0200
Anders Larsen <al@...rsen.net> wrote:

> On 2009-07-10 02:01:37, Alan Cox wrote:
> > > shouldn't it be
> > > +	if (likely(!port->console || !port->sysrq))
> > > respectively
> > > +	if (unlikely(port->console && port->sysrq)) {
> > > 
> > > at least for clarity?
> > 
> > It'll get predicted by the CPU just fine I suspect.
> 
> I thought likely() / unlikely() were for the _compiler_ to arrange the
> blocks more efficiently?

Bit of both. Some systems have indicators for whether jumps are likely to
be taken, others you do things like conditionally jump forward to a jump
table which jumps back.

gcc itself says "programmers are notoriously bad at predicting how their
programs actually perform." 8)

Benchmarking I've not had any luck with unlikely() on a modern CPU
(the CPU is dynamically predicting anyway). The pentium iv does add
branch prediction hints (DS: and CS: overrides get reused) but they seem
to make things slower in the case where the CPU will get it right anyway.

So I'd like to see benchmarking evidence for an unlikely on such a hot
and predictible path.

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