On Mon, Sep 02, 2013 at 03:50:34PM +0200, Stanislaw Gruszka wrote:
> On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
> > > Hope this may help.
> > > I've added a silly check to make sure that `stime < rtime'
> > >
> > > @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
> > > if (total) {
> > > stime = scale_stime((__force u64)stime,
> > > (__force u64)rtime, (__force
> > > u64)total);
> > > + if (stime > rtime) {
> > > + printk(KERN_ERR "Ooops: stime:%llu rtime:%llu\n",
> > > stime, rtime);
> > > + WARN_ON(1);
> > > + }
> > > utime = rtime - stime;
> > > } else {
> > > stime = rtime;
> [snip]
>
> > Thanks a lot Sergey for testing this further!
> >
> > Interesting results, so rtime is always one or two units off stime after
> > scaling.
> > Stanislaw made the scaling code with Linus and he has a better idea on the
> > math guts
> > here.
>
> I don't think this is scale issue, but rather at scale_stime() input
> stime is already bigger then rtime. Sergey, could you verify that
> by adding check before scale_stime() ?
Note that having stime > rtime should be fine to handle. This can happen for
example if the task runs on tiny timeslices but is unlucky enough that all these
timeslices are interrupted by the tick.
>
> Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
