[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1186113467.3996.0.camel@laptopd505.fenrus.org>
Date: Thu, 02 Aug 2007 20:57:47 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Matt Mackall <mpm@...enic.com>
Cc: Ingo Molnar <mingo@...e.hu>, Roman Zippel <zippel@...ux-m68k.org>,
Mike Galbraith <efault@....de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: CFS review
On Thu, 2007-08-02 at 22:04 -0500, Matt Mackall wrote:
> On Wed, Aug 01, 2007 at 01:22:29PM +0200, Ingo Molnar wrote:
> >
> > * Roman Zippel <zippel@...ux-m68k.org> wrote:
> >
> > > [...] e.g. in this example there are three tasks that run only for
> > > about 1ms every 3ms, but they get far more time than should have
> > > gotten fairly:
> > >
> > > 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt
> > > 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt
> > > 4546 roman 20 0 1796 344 256 R 31.7 0.3 0:21.07 lt
> > > 4547 roman 20 0 1532 272 216 R 3.3 0.2 0:01.94 l
> >
> > Mike and me have managed to reproduce similarly looking 'top' output,
> > but it takes some effort: we had to deliberately run a non-TSC
> > sched_clock(), CONFIG_HZ=100, !CONFIG_NO_HZ and !CONFIG_HIGH_RES_TIMERS.
>
> ..which is pretty much the state of play for lots of non-x86 hardware.
question is if it's significantly worse than before. With a 100 or
1000Hz timer, you can't expect perfect fairness just due to the
extremely rough measurement of time spent...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists