linux-kernel - Re: [PATCH v2 1/3] [RFC] Generic Red-Black Trees (performance notes)

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: <4FC90267.7050102@att.net>
Date:	Fri, 01 Jun 2012 12:56:55 -0500
From:	Daniel Santos <danielfsantos@....net>
To:	linux-kernel@...r.kernel.org
CC:	Kent Overstreet <koverstreet@...gle.com>, tj@...nel.org,
	Peter Zijlstra <peterz@...radead.org>, axboe@...nel.dk,
	paul.gortmaker@...driver.com, Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH v2 1/3] [RFC] Generic Red-Black Trees (performance notes)

I've done a bit more analysis of the generated code of
kernel/sched/fair.c (patched) under three versions of gcc.

gcc-4.5.3
* 48 bytes larger
* one instance of a (const_flag & ENUM_VALUE) fails to compile out
* compare function not inlined

gcc-4.6.2
* same size
* ANDed constants compiled out
* compare function inlined

gcc-4.7.0:
* 64 bytes smaller - __enqueue_entity() reduced by 16 bytes (2 byte
smaller and saved some padding, so essentially the same), I'm not sure
where the other 48 bytes came from, I'm guessing just alignment changes
from using different registers (smaller opcodes).

So in summary, the results on 4.5 are worse, but not "horrible".  The
problems are fixed in 4.6 and later.

There's still lots of other scenarios to test.

Daniel

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