linux-kernel - Re: [RFC 13/13] Char: nozomi, cleanup read and write

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:	Sun, 11 Nov 2007 03:37:28 +0100
From:	Frank Seidel <fseidel@...e.de>
To:	linux-kernel@...r.kernel.org
Cc:	Jiri Slaby <jirislaby@...il.com>, Adrian Bunk <bunk@...nel.org>
Subject: Re: [RFC 13/13] Char: nozomi, cleanup read and write

On Samstag 10 November 2007 23:04:41, you (Jiri Slaby) wrote:
> On 11/10/2007 05:15 PM, Adrian Bunk wrote:
> > On Fri, Nov 09, 2007 at 06:51:35PM -0500, Jiri Slaby wrote:
> >> ...
> >> -		if (size_bytes - i == 2) {
> >> +		if (unlikely(size_bytes - i == 2)) {
> >> ...
> > 
> > Please don't add likely/unlikely in drivers unless it brings a 
> > measurable improvement.
> Why? Anyway I think this is the case. The body of the then branch is executed at
> most once, while the else branch each time but last. If you write/read 1002
> bytes, it means 250:1. ...and it's invoked from interrupt too...

I just did some measurements of how often (under real life scenarios like
downloading big files, websurfing, chat and ssh sessions) those pathes are
used.

While in the read_mem32 the unlikekly really seems to be of no use at all (the
switch-case ahead seems to be hit nearly always), the unlikely in the 
write_mem32 seems to be fine.
I compared after each 30 seconds and got median ratio of 1381:1 (for the
likely path) after about 20 minutes, i see a range between 1046:1 and
3511:1. So i wouldn't call it a bad guess from my beginners point of view.

Thanks,
Frank

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