linux-kernel - Re: [performance bug] volanomark regression on 37-rc1

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: <AANLkTinU4rbj3VF6WsUE_M08vnECnY=h7L4o8ynaU5SP@mail.gmail.com>
Date:	Tue, 16 Nov 2010 08:21:40 -0800
From:	Nikhil Rao <ncrao@...gle.com>
To:	"Alex,Shi" <alex.shi@...el.com>
Cc:	a.p.zijlstra@...llo.nl, mingo@...e.hu,
	linux-kernel@...r.kernel.org, "Chen, Tim C" <tim.c.chen@...el.com>,
	zheng.z.yan@...el.com
Subject: Re: [performance bug] volanomark regression on 37-rc1

On Tue, Nov 16, 2010 at 1:34 AM, Alex,Shi <alex.shi@...el.com> wrote:
> When do performance testing on 37-rc1 kernel on Core2 machines, we find
> the volanomark loopback performance drop about 30%, that due to
> commit:fab476228ba37907ad7
>
> Volanomark link: http://www.volano.com/benchmarks.html
> Our volanomark testing parameters as following:
> "-count 25000 -rooms 10 "
> JVM is jrockit-R27.3.1-jre1.5.0_11
> java_options is "-Xmx1500m -Xms1500m -Xns750m -XXaggressive -Xlargepages
> -XXlazyUnlocking -Xgc:genpar -XXtlasize:min=16k,preferred=64k"
> and we set /proc/sys/kernel/sched_compat_yield as "1".
>
> We find if with the following patch, the regression can be recovered.
>
> Signed-off-by:Alex Shi <alex.shi@...el.com>
>
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index f4f6a83..5dca678 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -1766,7 +1766,6 @@ static void pull_task(struct rq *src_rq, struct task_struct *p,
>        check_preempt_curr(this_rq, p, 0);
>
>        /* re-arm NEWIDLE balancing when moving tasks */
> -       src_rq->avg_idle = this_rq->avg_idle = 2*sysctl_sched_migration_cost;
>        this_rq->idle_stamp = 0;
>  }
>
>
> It seems some of load_balance() is not necessary that caused by avg_idle
> setting. But do not know more details of the volano running. Anyone like
> to give a comments for this issue?
>

I'm not very familiar with the Volanomark benchmark, but from the
patch you posted it looks like resetting the idle throttle (i.e.
making newidle balance more likely) hurts this benchmark. This is also
evident in the sharp increase in ctx rate in 2.6.37-rc1. Resetting
throttling was a heuristic added to induce more frequent idle
balancing after a migration, and it isn't strictly required to make
the other parts of that patch work. In your patch above, can you
please also remove the comment and idle_stamp reset.


> Ncrao, I have no idea of your benchmarks, but just guess removing the
> avg_idle setting won't bring much wakeup delay for tasks. Could you like
> to show some data of this?
>

The benchmark was pretty simple; run nr_cpu while-1 loops, one of them
niced to -15. I also experimented with some payloads with random
sleep/wakeup times, but nothing with high frequency balancing. I think
removing the reset should be OK for the idle test cases.

-Thanks,
Nikhil
--
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/