linux-kernel - Re: [PATCH] sched: Check nr_running before calling pick_next

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: <CADZ9YHjrWC7Czc8JZu1W1AOi=X_+1Y_Abmra4aQfGNipFVqFZw@mail.gmail.com>
Date:	Sat, 9 Jul 2011 10:43:17 +0600
From:	Rakib Mullick <rakib.mullick@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Paul Turner <pjt@...gle.com>
Subject: Re: [PATCH] sched: Check nr_running before calling pick_next_task in schedule().

On Sat, Jul 2, 2011 at 8:26 PM, Rakib Mullick <rakib.mullick@...il.com> wrote:
> On Sat, Jul 2, 2011 at 3:51 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Sat, 2011-07-02 at 00:41 +0600, Rakib Mullick wrote:
>
>> You've completely failed to provide any sort of rationale for the patch
>> nor did you provide a use-case with performance numbers. This just isn't
>> making much sense at all.
>>
> Regarding taking branch, it needs performance numbers - I agree. But,
> I'm not quite agree that - it's not just making any sense. Will try to
> do some performance testing on it.

I tried to do some testing with the applied patch using kernbench
(with likely branch removed). I did it twice with load  -j {,2,4,6,8}.
Kernel version tagged with -schedpatch indicates kernel with this
applied and -noschedpatch is the default. In first case, with this
patch applied Elapsed time is lesser. In the second run with -j 2 and
-j 4 -schedpatch kernel is slow, but with -j 6 and -j 8 it takes less
elapsed time. Also tested with 'nosmp', with this patch, elapsed time
is lesser. So, for better interpretation and full log of test results
I'm attaching the kernbench.log. Please, see whether it looks
convincing to you or not. Tests are done on core i3 machine.


Thanks,
Rakib

Download attachment "kernbench.log" of type "application/octet-stream" (5358 bytes)