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

Powered by blists - more mailing lists