linux-kernel - Re: [PATCH] sched.c: Be a bit more conservative in SMP

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: <200609212036.24856.vincent.plr@wanadoo.fr>
Date:	Thu, 21 Sep 2006 20:36:18 +0200
From:	Vincent Pelletier <vincent.plr@...adoo.fr>
To:	Ludovic Drolez <ldrolez@...box.com>
Cc:	Antonio Vargas <windenntw@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched.c: Be a bit more conservative in SMP

Le mercredi 20 septembre 2006 09:42, Ludovic Drolez a écrit :
> Yes ! That might be a better idea !
> In fact, I tested the 1st patch on our cluster (Finite elements computing
> on 8 CPUs):
> - Under Windows: 875 seconds
> - Linux 2.6.16 : 1019 s
> - Linux 2.6.16 + manual taskset : 842 s
> - Linux 2.6.16 + Vincent's patch : 1373 s  :-(

I was afraid of this :/.
I did some quick tests, and I got non-significant results. I tried building a 
kernel with different make -j parameters, and there was like a few seconds of 
difference, and not always in favour of the same version.

I find it strange that you get such horrible results...
Maybe I was completely wrong with my assumption that one running process 
always has an impact of 1, which would have make the scheduler underestimate 
the load on one cpu and put too many processes on it, without moving them 
afterward.

-- 
Vincent Pelletier

Content of type "application/pgp-signature" skipped