Date: Sun, 21 Jan 2001 18:03:40 -0800 From: Peter Wemm <peter@netplex.com.au> To: John Baldwin <jhb@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jason Evans <jasone@FreeBSD.org> Subject: Re: cvs commit: src/sys/alpha/include mutex.h src/sys/i386/inclu Message-ID: <200101220203.f0M23ek09758@mobile.wemm.org> In-Reply-To: <XFMail.010121173615.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On 21-Jan-01 Julian Elischer wrote: > > What is the reasoning? (not complaining, just curious) > > Inlining all of these can bloat the kernel unfortunately. Jason estimated > 650kb of extra code in a non-debug kernel from this when we hit 5.0. There is a crossover point between cost of burning up L1 and L2 cache compared to the cost of a function call. Inlining usually increases the speed of microbenchmarks that are focussed on one particular subsystem, but at the overall expense of the rest of the system as there is now less cache to go around. This shows up in things like having microbenchmarks going slightly faster but slowing down things like 'make world' etc. There are lots of pros and cons each way. But right now with all this inlined it is quite difficult to debug as there is no stack frame. When some random blob of code faults it can be quite a mystery to figure out where the hell you are in ddb unless you have a very good recognition of what all the inline generated code looks like. This may not be the final form, but at least it gives us less headaches trying to do debugging. And debugging is something that we need no extra pain over right now. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101220203.f0M23ek09758>