linux-kernel - Re: [PATCH] Scheduler: Improving the scheduler performance.

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: <8762.1176044803@turing-police.cc.vt.edu>
Date:	Sun, 08 Apr 2007 11:06:43 -0400
From:	Valdis.Kletnieks@...edu
To:	root <swordfish@...tbd.com>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Scheduler: Improving the scheduler performance.

On Sat, 07 Apr 2007 23:42:20 +0600, root said:

> As we know that, linux scheduler use separate runqueue for every CPU of
> a multiprocessor system, which having an active and an expired array.If
> we use only one expired array, then the CPUs of a multiprocessor system
> will be able to share their expired task via the accumulated expired
> array,

I got this far, and the first thought that popped into my head was:

"Wow.  This might actually win on a UP or small MP (2-15 CPU).  But the
lock contention on a big 512-CPU machoflops box is likely going to *suck*".

For that matter, my quick eyeballing of the code, although it doesn't *find*
any race conditions, doesn't convince me there's any protection taken to make
sure there aren't any.  Is there some subtle algorithmic trick I'm missing
to ensure Nothing Bad Can Happen?

Content of type "application/pgp-signature" skipped