Messages in this thread | | | Subject | Re: [RFC] time: xtime_lock is held too long | From | Eric Dumazet <> | Date | Sat, 07 May 2011 07:02:32 +0200 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |