[lkml]   [2011]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] time: xtime_lock is held too long
Le vendredi 06 mai 2011 à 16:28 -0700, john stultz a écrit :

> Defeating seqlock power? My thoughts are that seqlocks are nice
> lightweight reader/writer locks that avoid writer starvation. You seem
> to be trying to redefine or extend them to be something else which is
> more subtle.

All I am trying to explain is that a seqlock is a compound of two
things : One spinlock to synchronize writers among themselves, one
seqcount to synchronize readers with a writer.

But the API provides only a compound one. Writer uses the whole locking,
while it would be nice to be able to separate the two steps. Note that
because write_seqlock() and write_sequnlock() are inlined, this would
not increase text size.

One another problem is that spinlock is in same cache line than
seqcount, while a reader doesnt need the spinlock.

> I agree, the code is complex! I'm just not sure adding more
> complicated/subtle locking mechanisms is a good solution. Instead I'd
> suggest simply splitting up the locks (by using new locks) to reduce the
> amount of data that is being protected by a single lock.
> But again, maybe I'm misunderstanding you?

Adding locks might be fine, I really dont know yet. Its adding yet
another pieces of memory to be dirtied. And total number of cache lines
to be dirtied gives the latency.

I would like to have a ktime_get() service as fast as possible, with
guarded latencies.

Typical workloads need to call it hundred of thousands times per second.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-05-07 07:05    [W:0.097 / U:34.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site