[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170322123728.wjqy4sr2d2zsfqan@hirez.programming.kicks-ass.net>
Date: Wed, 22 Mar 2017 13:37:28 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Byungchul Park <byungchul.park@....com>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org,
juri.lelli@...il.com, rostedt@...dmis.org, kernel-team@....com
Subject: Re: [PATCH v2] sched/deadline: Make find_later_rq() choose a closer
cpu in topology
On Tue, Mar 21, 2017 at 04:52:24PM +0900, Byungchul Park wrote:
> When cpudl_find() returns any among free_cpus, the cpu might not be
> closer than others, considering sched domain. For example:
>
> this_cpu: 15
> free_cpus: 0, 1,..., 14 (== later_mask)
> best_cpu: 0
>
> topology:
>
> 0 --+
> +--+
> 1 --+ |
> +-- ... --+
> 2 --+ | |
> +--+ |
> 3 --+ |
>
> ... ...
>
> 12 --+ |
> +--+ |
> 13 --+ | |
> +-- ... -+
> 14 --+ |
> +--+
> 15 --+
>
> In this case, it would be best to select 14 since it's a free cpu and
> closest to 15(this_cpu). However, currently the code select 0(best_cpu)
> even though that's just any among free_cpus. Fix it.
This would result in picking the HT sibling, if available. Which is
typically the worst possible pick.
If you add support for SD_PREFER_SIBLING, which denotes a preference for
any other sibling domain above this one, this might work.
Powered by blists - more mailing lists