[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201103302117.HAF43299.HVOSFQOFJMFOtL@I-love.SAKURA.ne.jp>
Date: Wed, 30 Mar 2011 21:17:29 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: peterz@...radead.org
Cc: rostedt@...dmis.org, mingo@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC] seqlock,lockdep: Add lock primitives to read_seqbegin().
Peter Zijlstra wrote:
> > Also, I assume you meant to call
> > spin_acquire() before entering the spin state (as with
> >
> > static inline void __raw_spin_lock(raw_spinlock_t *lock)
> > {
> > preempt_disable();
> > spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
> > LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
> > }
> >
> > . Otherwise, lockdep cannot report it when hit this bug upon the first call to
> > this function).
>
> Huh no, of course not, a seqlock read side cannot contend in the classic
> sense.
I couldn't understand what 'contend' means. I think
static __always_inline unsigned read_seqbegin(const seqlock_t *sl)
{
unsigned ret;
repeat:
ret = sl->sequence;
smp_rmb();
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
return ret;
}
is equivalent (except that above one will not write to any kernel memory) to
static __always_inline unsigned read_seqbegin(seqlock_t *sl)
{
unsigned ret;
unsigned long flags;
spin_lock_irqsave(&sl->lock, flags);
ret = sl->sequence;
spin_unlock_irqrestore(&sl->lock, flags);
return ret;
}
because read_seqbegin() cannot return to the reader until the writer (if there
is one) calls write_sequnlock().
static inline void write_seqlock(seqlock_t *sl)
{
spin_lock(&sl->lock);
++sl->sequence;
smp_wmb();
}
static inline void write_sequnlock(seqlock_t *sl)
{
smp_wmb();
sl->sequence++;
spin_unlock(&sl->lock);
}
Don't we call this situation (a reader thread temporarily behaves like a writer
thread who writes nothing) as 'contended'?
Anyway, could you show me read_seqbegin2()/read_seqretry2() for testing with
locktest module?
Regards.
--
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