Messages in this thread | | | Date | Tue, 1 Apr 2008 10:38:41 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: spinlocks -- why are releases inlined and acquires are not? |
| |
On Tue, 1 Apr 2008, Ingo Molnar wrote:
> > > What is the reason for this asymetry? Shouldn't the acquiring > > > functions be implemented in the very same way? Or at least, > > > shouldn't all the __lockfunc functions be inlined? > > i.e. is there any particular reason why we don't have something like > > the patch below (implemented for all the lock variants of course, this > > is just to demonstrate what I mean)? > IIRC the main reason we decided to uninline them was image size. So i'd > suggest for you to check how this change impacts vmlinux size (on both > 64-bit and 32-bit), a typical distro config (or allyesconfig with lock > debugging disabled). If you do the test on x86.git/latest you'll also > have the CONFIG_OPTIMIZE_INLINING=y and CONFIG_CC_OPTIMIZE_FOR_SIZE=y > combination as well, which generates the most compact x86 kernel image > ever.
In fact we have received report from one of our users that he is seeing approximately 15% performance degradation of mmap() when spinlocks are not inlined. I am going to do some performance measurements myself shortly, as it seems quite strange, but while at it, I have noticed the aforementioned asymetry in spinlock.h, so I just wanted to know if there is any particular reason behind that.
-- Jiri Kosina SUSE Labs
| |