Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2899809ybz; Mon, 27 Apr 2020 06:38:50 -0700 (PDT) X-Google-Smtp-Source: APiQypKIIHMEgMQgtWpc55F0PLm/IRSzLa13JN8JP0rVeJSy8YCtLL6TgTQOKJ1x74NOknzjbZOZ X-Received: by 2002:a05:6402:684:: with SMTP id f4mr18994249edy.240.1587994730743; Mon, 27 Apr 2020 06:38:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587994730; cv=none; d=google.com; s=arc-20160816; b=go2xKPaztBnbXVbQyBdANmTbl4ktVQE0D2gdDFeP3nj0Chz2gjkOs2VxCL3ZzrZrqn 2ziyxFrkdnnm+cPYwdatU+YDIBnTejagOdA+UwydGW+HT0hJX5BcebSuBdPVxgiYMbAQ H5JD8wvvdx2NcTIeLrgAtmP9U5kyxkc3I4UT9F32ZCb2R1WOk7+we0Aitra+bRTt87BH V6bL51rQklbjYA+e3BN8yI2JTkzYmyuK9PK4Nz3Vz31QPQt2/71hfsgu9Iatyd5TN5ZA unF70Jgl7lf/m/mSc0wTMwfahsxAc03HJy8uhF1zzA3yUYOjd36LEDsBjD/wrE1sIkV8 RqKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=hCIx+uylxDiIkQIo7KO6BB1dE1p8+oU0uTFZQetsf50=; b=qXMEivlT88np669HMxs1XtYiG/SiwfShr3My0cj8jNNHi0p+7j4Fph9+5z7aZJ8sxa HlmK64rpPEhA7MBr2v2O3CeJaMUyBD7AsCP9uNvHFES8QwmhD0cYsKrjeQpVEVu9AYwt KqDQ48dS4bOXSNgseCsnKWGaFvtD6tDQY1hsd9dB/08taw3HjYWSPsnvv0Na2LcKUTAk raL5XVuUy4FOP8Q5HbR9MKIEXMRanepbAJzJTXJHTuZJQqgUlubfMhTlIltfRzY6R+r8 eqw/E4HhCaY57cxnUNCJw4IZO0LpU9357DwY0oYxoexBb2mSunHy79yf8RW2wJ/dl0rw CVyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eWsiqAfD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h5si8012311ejx.174.2020.04.27.06.38.27; Mon, 27 Apr 2020 06:38:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eWsiqAfD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727077AbgD0Neq (ORCPT + 99 others); Mon, 27 Apr 2020 09:34:46 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:36938 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726651AbgD0Nep (ORCPT ); Mon, 27 Apr 2020 09:34:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587994484; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hCIx+uylxDiIkQIo7KO6BB1dE1p8+oU0uTFZQetsf50=; b=eWsiqAfDllpkf3sf9ed5i7DugdqymnPVy+H/HG6LZNeekaj5Ata8ZqSeWaC7DLTKQQVVZq domXIMbGtScEa1ErcRYEP4R044KQz+y5YoTF+gQlfr8DKVqpR04rCf58L9wP6mRd4mUx3+ O47rKjolGj96UTIyftEO1hiwqVDSKNA= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-394-7plCh5oWNpCIucYQSc93jQ-1; Mon, 27 Apr 2020 09:34:43 -0400 X-MC-Unique: 7plCh5oWNpCIucYQSc93jQ-1 Received: by mail-wm1-f70.google.com with SMTP id 72so21444wmb.1 for ; Mon, 27 Apr 2020 06:34:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hCIx+uylxDiIkQIo7KO6BB1dE1p8+oU0uTFZQetsf50=; b=Xvh3D8bjhkbMZgU2S+5rgcZX5YVo+uMyOKg5ipZaNiD+KWVqa1m7bJkxRWYblfTHXi SiKmsQFPt4U8UqjlAi4IeRjFrk1J1Wd8mumObK6VwgiHp8Mxgeaq4D4iZRm+gJbrZrl4 aTSSr4h8SGxXodgqBA07uzRMpaTlMIQRdjpsBh+HGVuDeCFU5Ufh1Ju3QYjxJCraJ5Qi YBh0aR6Jqa0VJ8lBbxIivQBuRu8vTCqcAsx1RPtaVSdZOVTaIAwRY8EcILXx9sN4OSK0 84Dw6bi6ypScDo0Rmwj/vjd0G7pItZIOiGp3mJpoSX2vFpbYEvTxPv7KyEc3VleuYMii 3vbA== X-Gm-Message-State: AGi0Pub0HiH6V8nL7udPOVsEOTxD0/R6xTEiVd8+c5f/rQx/aopQLtTB zZomg+x2hjushX+ywlenCmI474FwjRCWUvSqzeQzbszAaK+Bz4T2Vx0i40z5iG+OTaZO8uLtD1P lSM2by4MjqKz4L41/lMwCn6L4 X-Received: by 2002:a1c:2383:: with SMTP id j125mr25781800wmj.6.1587994481714; Mon, 27 Apr 2020 06:34:41 -0700 (PDT) X-Received: by 2002:a1c:2383:: with SMTP id j125mr25781773wmj.6.1587994481373; Mon, 27 Apr 2020 06:34:41 -0700 (PDT) Received: from localhost.localdomain ([151.29.194.179]) by smtp.gmail.com with ESMTPSA id r3sm22287559wrx.72.2020.04.27.06.34.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 06:34:40 -0700 (PDT) Date: Mon, 27 Apr 2020 15:34:38 +0200 From: Juri Lelli To: Dietmar Eggemann Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Steven Rostedt , Luca Abeni , Daniel Bristot de Oliveira , Wei Wang , Quentin Perret , Alessio Balsini , Pavan Kondeti , Patrick Bellasi , Morten Rasmussen , Valentin Schneider , Qais Yousef , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 6/6] sched/deadline: Implement fallback mechanism for !fit case Message-ID: <20200427133438.GA6469@localhost.localdomain> References: <20200427083709.30262-1-dietmar.eggemann@arm.com> <20200427083709.30262-7-dietmar.eggemann@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200427083709.30262-7-dietmar.eggemann@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 27/04/20 10:37, Dietmar Eggemann wrote: > From: Luca Abeni > > When a task has a runtime that cannot be served within the scheduling > deadline by any of the idle CPU (later_mask) the task is doomed to miss > its deadline. > > This can happen since the SCHED_DEADLINE admission control guarantees > only bounded tardiness and not the hard respect of all deadlines. > In this case try to select the idle CPU with the largest CPU capacity > to minimize tardiness. > > Signed-off-by: Luca Abeni > Signed-off-by: Dietmar Eggemann > --- > kernel/sched/cpudeadline.c | 19 +++++++++++++++---- > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c > index 8630f2a40a3f..b6c7a0bc0880 100644 > --- a/kernel/sched/cpudeadline.c > +++ b/kernel/sched/cpudeadline.c > @@ -121,19 +121,30 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p, > > if (later_mask && > cpumask_and(later_mask, cp->free_cpus, p->cpus_ptr)) { > - int cpu; > + unsigned long cap, max_cap = 0; > + int cpu, max_cpu = -1; > > if (!static_branch_unlikely(&sched_asym_cpucapacity)) > return 1; > > /* Ensure the capacity of the CPUs fits the task. */ > for_each_cpu(cpu, later_mask) { > - if (!dl_task_fits_capacity(p, cpu)) > + if (!dl_task_fits_capacity(p, cpu)) { > cpumask_clear_cpu(cpu, later_mask); > + > + cap = capacity_orig_of(cpu); > + > + if (cap > max_cap) { > + max_cap = cap; > + max_cpu = cpu; > + } > + } > } > > - if (!cpumask_empty(later_mask)) > - return 1; > + if (cpumask_empty(later_mask)) > + cpumask_set_cpu(max_cpu, later_mask); Think we touched upon this during v1 review, but I'm (still?) wondering if we can do a little better, still considering only free cpus. Can't we get into a situation that some of the (once free) big cpus have been occupied by small tasks and now a big task enters the system and it only finds small cpus available, were it could have fit into bigs if small tasks were put onto small cpus? I.e., shouldn't we always try to best fit among free cpus? Thanks, Juri