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]
Message-ID: <20120312161743.GB2607@redhat.com>
Date:	Mon, 12 Mar 2012 12:17:43 -0400
From:	Jason Baron <jbaron@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 5/7] x86/jump labels: Use etiher 5 byte or 2 byte jumps

On Thu, Mar 08, 2012 at 05:17:35PM -0500, Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@...hat.com>
> 
> Have the jump labels add a "jmp" in the assembly instead
> of a default nop. This will cause the assembler to put in
> either a 2 byte or 5 byte jmp depending on where the target
> lable is.
> 
> Then at compile time, the update_jump_label code will replace
> the jmps with either 2 or 5 byte nops.
> 
> On boot up, the code can be examined to see if the jump label
> uses either a 2 or 5 byte nop and replace it.
> 
> By allowing the jump labels to be 2 bytes, it speeds up the
> nops, not only 2 byte nops are faster than 5 byte nops, but also
> because it saves on cache foot print.
> 
>    text    data     bss     dec     hex filename
> 13403667 3666856 2998272 20068795 13239bb ../nobackup/mxtest/vmlinux-old
> 13398536 3666856 2998272 20063664 13225b0 ../nobackup/mxtest/vmlinux-new
> 
> Converting the current v3.2 trace points saved 5,131 bytes.
> As more places use jump labels, this will have a bigger savings.
> 

Hi Steven,

Strange. I'm not seeing the text size savings with this patch, relative
to the 'old' jump label compiled code. Is your comparison against jump
labels disabled?

Here's the size without your patch 'CONFIG_JUMP_LABEL' set:

   text    data     bss     dec     hex filename
10809465        1023976 1159168 12992609         c64061 vmlinux

And with your patches and 'CONFIG_JUMP_LABEL' set:

   text    data     bss     dec     hex filename
10812613        1023976 1163264 12999853         c65cad vmlinux

So an increase in text of 3148. Which is not completely explained by the
increase in arch/x86/kernel/jump_label.o:

without your patch 'CONFIG_JUMP_LABEL' set:

   text    data     bss     dec     hex filename
    229       0       0     229      e5 arch/x86/kernel/jump_label.o


with your patch 'CONFIG_JUMP_LABEL' set:

   text    data     bss     dec     hex filename
    943       0       8     951     3b7 arch/x86/kernel/jump_label.o

So jump_label.o is 714 bytes larger, which is not enough to explain the
3148 byte increase.

I'm using gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1).

Can you please double check the savings.

Thanks,

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