In-Reply-To: <[email protected]>
On Tue, 7 Mar 2006 16:15:50, Andrew Morton wrote:
> Chuck Ebbert <[email protected]> wrote:
> > Fastpath before patch:
> > jle <keep looping> not-taken conditional jump
> > cli disable interrupts
> > jmp <try for lock> unconditional jump
> >
> > Fastpath after patch, if interrupts were not enabled:
> > jg <try for lock> taken conditional branch
> >
>
> Well no. The fastpath is:
>
> jns 4f we got the lock.
That's debatable. Once the spinlock is available, jumping back to
try and get it becomes fastpath code, even though the spinloop itself
is not. Any delay seen here means lost cycles that could be doing work.
My only real question is how long 'cli' takes if interrupts are already
disabled.
> And it's increasing text size. Which wouldn't be a big problem if the
> spinning code was still in an out-of-line section, but it isn't any more.
__raw_spin_lock_flags is inlined, but only one place, in
_spin_lock_irqsave(), which is no longer an inline. So there's no real
need to out-of-line the spin code anymore. This adds nine bytes, which
should be acceptable in an out-of-line function. (Only the unlock functions
are inlined, and even then only if !CONFIG_PREEMPT).
--
Chuck
"Penguins don't come from next door, they come from the Antarctic!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
