[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070328070459.GC12508@wotan.suse.de>
Date: Wed, 28 Mar 2007 09:04:59 +0200
From: Nick Piggin <npiggin@...e.de>
To: Oleg Nesterov <oleg@...sign.ru>
Cc: Ravikiran G Thirumalai <kiran@...lex86.org>,
Ingo Molnar <mingo@...e.hu>,
Nikita Danilov <nikita@...sterfs.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [patch] queued spinlocks (i386)
On Sun, Mar 25, 2007 at 07:54:07PM +0400, Oleg Nesterov wrote:
> I am sorry for being completely off-topic, but I've been wondering for the
> long time...
>
> What if we replace raw_spinlock_t.slock with "struct task_struct *owner" ?
>
> void _spin_lock(spinlock_t *lock)
> {
> struct task_struct *owner;
>
> for (;;) {
> preempt_disable();
> if (likely(_raw_spin_trylock(lock)))
> break;
> preempt_enable();
>
> while (!spin_can_lock(lock)) {
> rcu_read_lock();
> owner = lock->owner;
> if (owner && current->prio < owner->prio &&
> !test_tsk_thread_flag(owner, TIF_NEED_RESCHED))
> set_tsk_thread_flag(owner, TIF_NEED_RESCHED);
> rcu_read_unlock();
> cpu_relax();
> }
> }
>
> lock->owner = current;
> }
>
> void _spin_unlock(spinlock_t *lock)
> {
> lock->owner = NULL;
> _raw_spin_unlock(lock);
> preempt_enable();
> }
>
> Now we don't need need_lockbreak(lock), need_resched() is enough, and we take
> ->prio into consideration.
>
> Makes sense? Or stupid?
Well with my queued spinlocks, all that lockbreak stuff can just come out
of the spin_lock, break_lock out of the spinlock structure, and
need_lockbreak just becomes (lock->qhead - lock->qtail > 1).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists