linux-kernel - Re: [PATCH 5/5] sched/rt: Optimize find_lowest

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:	Wed, 4 Feb 2015 21:07:57 +0800
From:	Xunlei Pang <pang.xunlei@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Juri Lelli <juri.lelli@...il.com>
Subject: Re: [PATCH 5/5] sched/rt: Optimize find_lowest_rq() to select a cache
 hot cpu

Hi Peter, Steve,

Thanks for all your valuable sharing.
I'll keep them in mind.

Regards,
Xunlei

On 30 January 2015 at 03:23, Peter Zijlstra <peterz@...radead.org> wrote:
> On Fri, Jan 30, 2015 at 12:42:47AM +0800, Xunlei Pang wrote:
>> On 27 January 2015 at 22:56, Steven Rostedt <rostedt@...dmis.org> wrote:
>> > On Tue, 27 Jan 2015 15:21:36 +0100
>> > Peter Zijlstra <peterz@...radead.org> wrote:
>> >
>> >> On Mon, Jan 19, 2015 at 04:49:40AM +0000, Xunlei Pang wrote:
>> >> > In find_lowest_rq(), if we can't find a wake_affine cpu from
>> >> > sched_domain, then we can actually determine a cache hot cpu
>> >> > instead of simply calling "cpumask_any(lowest_mask)" which
>> >> > always returns the first cpu in the mask.
>> >> >
>> >> > So, we can determine the cache hot cpu during the interation of
>> >> > sched_domain() in passing.
>> >>
>> >> Steve, I'm not getting this. Why are we using WAKE_AFFINE here?
>> >>
>> >
>> > It originated from Gregory Haskins topology patches. See
>> >  6e1254d2c41215da27025add8900ed187bca121d
>>
>> Hi Peter, Steve,
>>
>> I think the responsiveness is the most important feature for RT tasks,
>> so I think:
>> response latency > cache > SMT in significance.
>
> No, deterministic execution time is the utmost important feature. And
> for that SMT utterly blows. So much so in fact that rule #1 for -rt work
> is to disable SMT on your hardware.
>
> The same argument can be made for shared caches. If your !rt workload
> blows away the cache of the rt workload, you loose.
>
>> I was wondering if we can take the cpuidle state into account like
>> current find_idlest_cpu() for CFS?
>> cpupri_find() can be easily modified to indicate the CPUPRI_IDLE case,
>> then we can select
>> an optimal idle cpu to improve RT tasks' responsiveness. For other
>> cases(mostly non-idle cpu),
>> I think we can rely on the existent sched_domain iteraction to select
>> a cache-hot cpu without
>> caring too much about SMT.
>
> your patch calls something 'cache-hot' when crossing large numa domains,
> don't you think that's somewhat stretching the definition of hot?
--
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/