linux-kernel - Re: CFS review

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070803041808.GA6002@1wt.eu>
Date:	Fri, 3 Aug 2007 06:18:08 +0200
From:	Willy Tarreau <w@....eu>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Matt Mackall <mpm@...enic.com>, 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, 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 <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...

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 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/