Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754255AbdC1An6 (ORCPT ); Mon, 27 Mar 2017 20:43:58 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:57032 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753914AbdC1Any (ORCPT ); Mon, 27 Mar 2017 20:43:54 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 165.244.249.23 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Tue, 28 Mar 2017 09:42:28 +0900 From: Byungchul Park To: Juri Lelli CC: , , , , , Subject: Re: [PATCH 0/8] sched/deadline: Return the best satisfying affinity and dl in cpudl_find Message-ID: <20170328004228.GE21430@X58A-UD3R> References: <1490265163-29981-1-git-send-email-byungchul.park@lge.com> <20170327140507.GN10289@e106622-lin> MIME-Version: 1.0 In-Reply-To: <20170327140507.GN10289@e106622-lin> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB08/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/03/28 09:43:07, Serialize by Router on LGEKRMHUB08/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/03/28 09:43:08, Serialize complete at 2017/03/28 09:43:08 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2284 Lines: 68 On Mon, Mar 27, 2017 at 03:05:07PM +0100, Juri Lelli wrote: > Hi, > > On 23/03/17 19:32, Byungchul Park wrote: > > cpudl_find() is used to find a cpu having the latest dl. The function > > should return the latest cpu among ones satisfying task's affinity and > > dl constraint, but current code gives up immediately and just return > > fail when it fails at the test *only with* the maximum cpu. > > > > For example: > > > > cpu 0 is running a task (dl: 10). > > cpu 1 is running a task (dl: 9). > > cpu 2 is running a task (dl: 8). > > cpu 3 is running a task (dl: 2). > > > > where cpu 3 want to push a task (affinity is 1 2 3 and dl is 1). > > Hummm, but this should only happen if you disable admission control, > right? Otherwise task's affinity can't be smaller that 0-3. Hi Juri, Can I ask you what is addmission control? Do you mean affinity setting? And do you mean s/disable/enable? Or am I misunderstanding? > > > > In this case, the task should be migrated from cpu 3 to cpu 1, and > > preempt cpu 1's task. However, current code just returns fail because > > it fails at the affinity test with the maximum cpu, that is, cpu 0. > > > > This patch set tries to find the best among ones satisfying task's > > affinity and dl constraint until success or no more to see. > > > > Anyway, do you have numbers showing how common is you fail scenario? Actually, it very depends on how to set test environment. I can provide you ones which generate many fails. IMHO, it's not a matter of frequency but a matter of whether it works corrently. As you know, rt policy already works corrently regarding this problem. In other words, if there are dl tasks in a system like: task a (dl: 1) -+ -+ task b (dl: 2) -| -| task c (dl: 3) -| -| task d (dl: 4) -| -+- should be run on 4 cpus machine task e (dl: 5) -| task f (dl: 6) -| task g (dl: 7) -| task h (dl: 8) -+- should be run on 8 cpus machine task i (dl: 9) task j (dl: 10) IMHO, deadline scheduler should ensure most urgent tasks as many as the number of cpus in the system to be run, as long as their affinities are satisfied. What do you think about this? Thanks, Byungchul > It would be interesting to understand how much the slow path is actually > used, IMHO. > > Thanks, > > - Juri