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:	Fri, 23 Mar 2007 13:40:03 +1100
From:	"Con Kolivas" <ckolivas@...il.com>
To:	tim.c.chen@...ux.intel.com
Cc:	ck@....kolivas.org, linux-kernel@...r.kernel.org,
	kernel@...ivas.org
Subject: Re: RSDL 0.31 causes slowdown

On 23/03/07, Tim Chen <tim.c.chen@...ux.intel.com> wrote:
> Con,
>
> I've tried running Volanomark and found a 80% regression
> with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu
> system (4 cpus per socket, 8 cpus for system).
>
> The results are sensitive to rr_interval. Using Con's patch to increase
> rr_interval to a large value of 100,
> the regression reduced to 30% instead of 80%.
>
> I ran Volanomark in loopback mode with 10 chatrooms
> (20 clients per chatroom) configuration, with each client sending
> out 10000 messages.
>
> http://www.volano.com/benchmarks.html
>
> There are significant differences in the vmstat runqueue profile
> between the 2.6.21-rc4 and the one with RSDL.
>
> There are a lot less runnable jobs (see col 2) with RSDL 0.31  (rr_interval=15)
> and higher idle time.

Thanks Tim.

Volanomark is a purely yield() semantic dependant workload (as
discussed many times previously). In the earlier form of RSDL I
softened the effect of sched_yield but other changes since then have
made that softness bordering on a noop. Obviously when sched_yield is
relied upon that will not be enough. Extending the rr interval simply
makes the yield slightly more effective and is not the proper
workaround. Since expiration of arrays is a regular frequent
occurrence in RSDL then changing yield semantics back to expiration
should cause a massive improvement in these values, without making the
yields as long as in mainline. It's impossible to know exactly what
the final result will be since java uses this timing sensitive yield
for locking but we can improve it drastically from this. I'll make a
patch soon to change yield again.

--
-ck
-
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/

Powered by blists - more mailing lists