lkml.org 
[lkml]   [2011]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks
On 09/02/2011 01:27 PM, Linus Torvalds wrote:
> On Fri, Sep 2, 2011 at 1:07 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>> I don't know whether that fastpath code is small enough to consider
>> inlining everywhere?
> No.
>
> There's no point in inlining something that ends up containing a
> conditional function call: gcc will have to effectively save/restore
> registers around that thing anyway, so you lose a lot of the
> advantages of inlining. So I think it's better done as an out-of-line
> function, which I thought we did for spinlocks anyway.

Yes, lock currently out-of-line.

I should also make sure that unlock is also out of line when
paravirtualized.

> Also, do you run with CONFIG_OPTIMIZE_SIZE? Without that, gcc should
> be smart enough to make a "likely()" case be a fall-through.

Ah, I was wondering why I'd never seen likely/unlikely do anything
useful. With OPTIMIZE_SIZE=n, there's no point in explicitly moving the
slowpath out to a separate function.

So the only downside with this variant is that it breaks my design
criteria of making the generated code look identical to the the original
code when CONFIG_PARAVIRT_SPINLOCKS=n. But I don't know if that's an
actual downside in practice.

J


\
 
 \ /
  Last update: 2011-09-02 23:45    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog