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  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]
Date:	Thu, 3 May 2007 09:42:51 +0300
From:	Al Boldi <>
To:	William Lee Irwin III <>
Subject: Re: [ck] [REPORT] vs 2.6.21-sd046 vs 2.6.21-cfs-v6

William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >> That's odd. The ->load_weight changes should've improved that quite
> >> a bit. There may be something slightly off in how lag is computed,
> >> or maybe the O(n) lag issue Ying Tang spotted is biting you.
> On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
> > Is it not biting you too?
> I'm a kernel programmer. I'm not an objective tester.
> It also happens to be the case that I personally have never encountered
> a performance problem with any of the schedulers, mainline included, on
> any system I use interactively. So my "user experience" is not valuable.
> William Lee Irwin III wrote:
> >> Also, I should say that the nice number affairs don't imply fairness
> >> per se. The way that works is that when tasks have "weights" (like
> >> nice levels in UNIX) the definition of fairness changes so that each
> >> task gets shares of CPU bandwidth proportional to its weight instead
> >> of one share for one task.
> On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
> > Ok, but you can easily expose scheduler unfairness by using nice levels
> > as relative magnifiers; provided nice levels are implemented correctly.
> This doesn't really fit in with anything I'm aware of.

You are not the first person that doesn't understand what I'm talking about.  
Don't worry about it.

> William Lee Irwin III wrote:
> >> The other thing to do is try a different number of tasks with a
> >> different mix of nice levels. The weight w_i for a given nice
> >> level n_i should be the same even in a different mix of tasks
> >> and nice levels if the nice levels are the same.
> >> If this sounds too far out, there's nothing to worry about. You can
> >> just run the different numbers of tasks with different mixes of nice
> >> levels and post the %cpu numbers. Or if that's still a bit far out
> >> for you, a test that does all this is eventually going to get written.
> On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
> > chew.c does exactly that, just make sure sched_granularity_ms >=
> > 5,000,000.
> Please post the source of chew.c




View attachment "chew.c" of type "text/x-csrc" (1137 bytes)

Powered by blists - more mailing lists