Messages in this thread | | | Date | Wed, 22 Jun 2005 01:48:08 -0400 | From | Chuck Ebbert <> | Subject | Re: [RFC] exit_thread() speedups in x86 process.c |
| |
On Tue, 14 Jun 2005 10:43:03 +0300, Denis Vlasenko wrote:
> On Tuesday 14 June 2005 07:26, cutaway@bellsouth.net wrote: > > The problem with that approach is GCC would still just relocate the push/pop > > block to the bottom of the function. This means you won't be likely to pick > > up anything useful in L1 or L2 as the function exits normally - in fact > > you'd typically be guaranteed to be picking up a partial line of gorp that > > is completely worthless later on. > > > > This is one of my issues with the notion of unlikely() being smoothed on > > everywhere like Bondo<g> - it also makes it "unlikely" that you'll get any > > serendipitous L1/L2 advantages that could be had by locating related > > functions next to each other. > > > > When you take the unlikely stuff completely out of line in a seperate > > functions located elsewhere, the mainline code can make better use of the > > caches. The Intel parts thrive on L1 hits and die if they're not getting > > them. > > That's exactly what compiler can do by itself. The fact that currently > it isn't smart enough to od it means that it has to be improved. > You propose that people have to do compiler's job.
Not just the compiler -- the linker would need to be a lot smarter too:
/* foo.c */
extern int bar1(void), bar2(void), bar3(void);
main() { if (likely(bar1())) bar2(); else bar3(); }
/* bar.c */
int bar1(void) { return 1; } int bar2(void) { whatever; } int bar3(void) { whatever; }
When you compile bar.c the compiler has _no_ idea which functions are likely to be called.
And doing this manually is trivial:
1. Add two sections to vmlinux.lds.S: .fast.text and .slow.text 2. Define __fast __attribute__(__section__(".fast.text")) 3. Define __slow similarly 4. Start tagging functions with __fast and __slow as needed
Very little work for much potential gain, AFAICS.
-- Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |