linux-kernel - RE: Re: sched_yield proposals/rationale

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] [day] [month] [year] [list]

Message-ID: <585DC2133F7C974F87D4EC432896F1720313698E@CORPUSMX10A.corp.emc.com>
Date:	Wed, 18 Apr 2007 01:40:14 -0400
From:	Buytaert_Steven@....com
To:	<davidsen@....com>, <linux-kernel@...r.kernel.org>
Cc:	<andi@...stfloor.org>, <linux-kernel@...r.kernel.org>
Subject: RE:  Re: sched_yield proposals/rationale

> -----Original Message-----
> From: linux-kernel-owner@...r.kernel.org [mailto:linux-kernel-
> owner@...r.kernel.org] On Behalf Of Bill Davidsen
> Sent: dinsdag 17 april 2007 21:38
> To: linux-kernel@...r.kernel.org
> Cc: Buytaert, Steven; andi@...stfloor.org; linux-kernel@...r.kernel.org
> Subject: Re: sched_yield proposals/rationale
> 
> Mark Lord wrote:
> >
> > Cool.  You *do know* that there is a brand new CPU scheduler
> > scheduled to replace the current one for the 2.6.22 Kernel, right?
> >
> Having tried both nicksched and Con's fair sched on some normal loads,
> as opposed to benchmarks, I sure hope Linus changes his mind about
> having several schedulers in the kernel. The "one perfect and
> self-adjusting scheduler" isn't here yet.

I have the same opinion, and it is still a long time out I'm afraid. Probably people only read my suggestion for a 'fix' diagonally, let alone they read my footer. Too bad the archives only go back to 95, I would love to retrieve my posts from 93. Anybody still have these?

Now a bit more on topic:

1) My problem is/was solved by making the default time slice much smaller than the default 100 in a 250Hz system. But that's only masking it away.

2) I made a schedstat program sort of like vmstat that samples and prints deltas each second (from /proc/schedstat). Just printing the jiffies delta and the # times schedule is called per CPU, is already thought provoking; a small 12 second example:

2.6.16 vanilla scheduler

   Jiffies CPU0    CPU1
    Delta 
    250  | 1756 |  7301 |
    252  | 1730 |  2638 |
    254  | 1963 |  1663 |
    385  |  868 |   658 | <--- stall starts
    325  |  138 |   112 |
    330  |  184 |   130 |
    339  |  682 |   122 |
    335  |  367 |   159 |
    334  |  653 |   127 |
    345  |  467 |   137 |
    335  |  673 |   128 |
    337  |  471 |   131 |
    334  |  673 |   127 |
    332  |  321 |   144 |
    333  |  523 |   129 |
    332  |   98 |   123 |
    356  |  496 |   124 |
    270  |   96 |    87 |
    277  | 5878 | 26228 | <-- yes 26K
    252  |18263 | 19130 | ...
    255  | 2024 |  5747 | <-- back to normal

Let's talk about fairness when we get the basics right. And yes, the real physical elapsed time per line IS 1 second, so the jiffies jumping up from the normal expected value of 250 to up to 356 is not normal; it's in fact very very bad. This box was unusable for 13 seconds in a row.

But this doesn't look serious enough to most people, it seems. 

Steven Buytaert
--
La perfection est atteinte non quand il ne reste rien ajouter, mais quand il ne reste rien à enlever. (Antoine de Saint-Exupéry)
-
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/