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
| ||
|
Date: Tue, 6 Oct 2009 17:14:36 -0700 (PDT) From: Roland McGrath <roland@...hat.com> To: Richard Henderson <rth@...hat.com> Cc: Jason Baron <jbaron@...hat.com>, linux-kernel@...r.kernel.org, mingo@...e.hu, mathieu.desnoyers@...ymtl.ca, tglx@...utronix.de, rostedt@...dmis.org, ak@...e.de, mhiramat@...hat.com Subject: Re: [PATCH 0/4] jump label patches > At present, the asm goto extension gives no prediction weights to any > path. I had hoped that the -freorder-blocks pass (enabled with -O2) > would automatically place the relevant fallthrough blocks immediately > after the asm goto. It did happen for small test cases, but a message > from Jason downthread indicates that it doesn't always happen. Kernel builds usually use -Os. Is there anything else we can do now (4.4) to influence this placement (while keeping the unlikely target block inside a scope, i.e. macro, with the asm goto)? Also note that another usage pattern I'm considering for the general case would (via fancy macros) look something like: if (({ __label__ yes; int maybe = 0; asm goto ("jmp %l[yes]" ::: yes); if (0) yes: maybe = 1; maybe; })) doit(); else dontit(); So please also advise on making something of that character come out optimal. > > if (__builtin_expect(0,0)) do_trace: __attribute__((cold)) { ... } > > An attribute cold on a label is something that I've suggested, but have > not yet implemented. I think that might be the easiest way to add > prediction weights to an asm goto. Ok. That syntax is accepted already now (4.4.1 anyway) but always generates: warning: ?cold? attribute ignored so it would be annoying to start using it now before compiler-version conditionals for a version where it does at most nothing. Btw, if you do make that work I think it would be nice (and seems like it would be not much different internally) to make: label: __attribute__ ((cold, section (".text.lukewarm"))) work too. I can see this being used for a few different kinds of things, where a specialized user like the kernel might want to segregate multiple different kinds of text. e.g., "really cold" for rare exception stuff, "tracepoint warm" for stuff that's cold by default but actually hot if lots of tracing is enabled, etc. Thanks, Roland -- 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