Re: [RFC] time: xtime_lock is held too long

[Eric Dumazet <eric.dumazet@gmail.com>]

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.