linux-kernel - Re: [test] hackbench.c interactivity results: vanilla versus SD/RSDL

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]

Date:	Sat, 31 Mar 2007 15:04:26 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Xenofon Antidides <xantidides@...oo.gr>
CC:	Ingo Molnar <mingo@...e.hu>, Con Kolivas <kernel@...ivas.org>,
	linux list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Galbraith <efault@....de>
Subject: Re: [test] hackbench.c interactivity results: vanilla versus SD/RSDL

Xenofon Antidides wrote:
> ----- Original Message ----
> From: Ingo Molnar <mingo@...e.hu>
> To: Con Kolivas <kernel@...ivas.org>
> Cc: linux list <linux-kernel@...r.kernel.org>; Andrew Morton <akpm@...ux-foundation.org>; Mike Galbraith <efault@....de>
> Sent: Thursday, March 29, 2007 9:22:49 PM
> Subject: [test] hackbench.c interactivity results: vanilla versus SD/RSDL
> 
> 
> * Ingo Molnar <mingo@...e.hu> wrote:
> 
> 
>>* Con Kolivas <kernel@...ivas.org> wrote:
>>
>>
>>>I'm cautiously optimistic that we're at the thin edge of the bugfix 
>>>wedge now.
> 
> [...]
> 
> 
>>and the numbers he posted:
>>
>> http://marc.info/?l=linux-kernel&m=117448900626028&w=2
> 
> 
> We been staring at these numbers for while now and we come to the conclusion they wrong.
> 
> The test is f is 3 tasks, two on different and one on same cpu as sh here:
> virgin 2.6.21-rc3-rsdl-smp
> top - 13:52:50 up 7 min, 12 users,  load average: 3.45, 2.89, 1.51
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
>  6560 root      31   0  2892 1236 1032 R   82  0.1   1:50.24 1 sh
>  6558 root      28   0  1428  276  228 S   42  0.0   1:00.09 1 f
>  6557 root      30   0  1424  280  228 R   35  0.0   1:00.25 0 f
>  6559 root      39   0  1424  276  228 R   33  0.0   0:58.36 0 f
> 
> 6560 sh is asking for 100% cpu on cpu number 1
> 6558 f is asking for 50% cpu on cpu number 1
> 6557 f is asking for 50% cpu on cpu number 0
> 6559 f is asking for 50% cpu on cpu number 0
> 
> So if 6560 and 6558 are asking for cpu from cpu number 1:
> 6560 wants 100% and 6558 wants 50%.
> 6560 should get 2/3 cpu 6558 should get 1/3 cpu

I don't think you can say that. If the 50% task alternated between
long periods of running and sleeping, then the end result should
approach a task that is sleeping for 50% of the time, and on the
CPU 25% of the time. As the periods get shorter, then the schedulers
will favour the 50% task relatively more, but details will depend on
implementation.

You could have an implementation that always gives runs the 50% task
when it becomes runnable, because it is decided that its priority is
higher because it has been sleeping.

The only thing you can really say is that the 50% task should get
between 25% and 50% (inclusive) CPU time.

-- 
SUSE Labs, Novell Inc.
-
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/