[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.080 / U:5.624 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site