On Thu, Aug 02, 2007 at 08:57:47PM -0700, Arjan van de Ven wrote:
> 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 <[email protected]> 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...
Well, at least we're able to *measure* that task 'l' used 3.3% and
that tasks 'lt' used 32%. If we're able to measure it, then that's
already fine enough to be able to adjust future timeslices credits.
Granted it may be rough for small periods (a few jiffies), but it
should be fair for larger periods. Or at least it should *report*
some fair distribution.
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
