lkml.org 
[lkml]   [2011]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] time: xtime_lock is held too long
On Thu, 5 May 2011, Eric Dumazet wrote:

> I feel xtime_lock seqlock is abused these days.
>
> seqlock abstraction is somewhat lazy/dangerous because write_sequnlock()
> does both the seqcount increment and spinlock release.
>
> I am concerned by fact that readers might wait for long times, because
> writers hold the whole seqlock, while sometime they only want to guard
> other writers to come in.
>
> Maybe it's time to separate the things (the seqcount and the spinlock)
> so that writer can manipulate data in different sections :
> - Sections while holding spinlock, allowing "readers" to run
> - Very small sections enclosed in a pair of seqcount increments, to
> synchronize with readers.

Well, in the case of timekeeping that might be problematic. I'm not
sure whether we can calculate the new values under the spinlock and
then update the timekeeper under the seqlock because we might adjust
the mult/shift pair which then can result in observabcle time going
backwards problems. It might be worth a try, though. John ???

The only thing which really can move right away outside the xtime
seqlock region is calc_global_load().

Thanks,

tglx



\
 
 \ /
  Last update: 2011-05-05 16:41    [W:1.093 / U:0.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site