[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7528b635-4a18-f449-ec70-f040a471c4f1@redhat.com>
Date: Tue, 21 Mar 2017 14:28:50 +0100
From: Daniel Bristot de Oliveira <bristot@...hat.com>
To: Byungchul Park <byungchul.park@....com>, peterz@...radead.org,
mingo@...nel.org
Cc: 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 03/21/2017 08:52 AM, 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.
That is a nice patch! But I wonder what would be the behavior with your
patch in the following hw:
# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14
node 0 size: 16159 MB
node 0 free: 15308 MB
node 1 cpus: 1 3 5 7 9 11 13 15
node 1 size: 16384 MB
node 1 free: 15028 MB
node distances:
node 0 1
0: 10 21
1: 21 10
-- Daniel
Powered by blists - more mailing lists