lkml.org 
[lkml]   [2009]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] itimers: fix racy writes to cpu_itimer fields

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Thu, 2009-09-24 at 19:57 +0200, Stanislaw Gruszka wrote:
> > On Thu, 24 Sep 2009 16:48:07 +0200
> > Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > > On Thu, 2009-09-24 at 16:35 +0200, Stanislaw Gruszka wrote:
> > > > incr_error and error fields of struct cpu_itimer are used when calculating
> > > > next timer tick in check_cpu_itimers() and should not be modified without
> > > > tsk->sighand->siglock taken.
> > >
> > > Won't it be all-round much better to convert these things to hrtimers
> > > instead of adding more and more fuzz on top to make them deal with
> > > jiffies?
> >
> > Perhaps it would, but I don't know how to do it :{ . Especially how to
> > precisely account user time. The only idea I have is make something like
> > microstate accounting (http://lwn.net/Articles/127296/), but this patch
> > and whole idea was rejected long time ago.
>
> That patch does look a little painful indeed.
>
> I was more thinking about about looking if an itimer was to expire less
> than 1 tick away on either sched-in or the tick.
>
> When we find it is indeed less than 1 tick away, program an hrtimer for
> that cpu to expire at the required moment, see hrtick_start().
>
> If we happen to de-schedule the task before the timer fires, we clear
> the hrtimer again (or let it pend and ignore the fire), see
> hrtick_clear().
>
> [ there is no reason to rely on the tick though, we can program the
> hrtimer on sched in to expire on at the right moment, and do so on
> each schedule for as long as an itimer is active - re-setting whatever
> pending timer the cpu still had. ]

we should think about the simplest approach: switching itimers to
hrtimers.

Ingo


\
 
 \ /
  Last update: 2009-09-24 22:23    [from the cache]
©2003-2011 Jasper Spaans