Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3756141yba; Tue, 7 May 2019 06:38:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqx0soPC/5w/Ny6HqSUrHNZ4vHTbEWb2A+zNrM++YtXyXQIqnY9eHWAX+jJZiPmv9WAMQ/zS X-Received: by 2002:a63:6ac3:: with SMTP id f186mr39240736pgc.326.1557236283350; Tue, 07 May 2019 06:38:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557236283; cv=none; d=google.com; s=arc-20160816; b=kzKjWGhoqgoflfchEasVyMzHCaf6s0YPmqtSvl/Blbfe6ZjprdsbdccCrfznT0igeV YkDu/n8e9YiiBaeEOkdCwv3DsFEDc09Ytv2E20n7hP6+fhg8HxLqG9pi1ABG7bvJjw9E j0T/4b3/lNU54PZagxOHjK5RDPTM+CSPZI8Kitfh+V90cKql0cf9khbBda3HDVVH0LJO RH8HhnW1LQ2QmFG846eRu1P8KsZZyDx9KpnsdjHyN29Oifl8kiCV6CS+l7LXfeqwibX5 vWAK0z92KgAfpiGHIYCPpUPWRRCUSxYbMZqX/IdzBrajyKSG0R2qW0FKLkktUwS/B2PR /qRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=YINIT4rQpGER+a1a5VYXLsBOW3NnN2xb5ZHvKxxk/aU=; b=e9W2Nn6V73IhD93t/BaOmG8JFzKZ7Ade2eI/0QdLm73fTjrDEG1BvDMyXHKA2oGjLM HC0op23L4jyQD5013jqxJtXrK5ugAAInjvEh8XCyVtgi17hhnIoieWfGGimh9VOuCNct yEHcew3S/WvZGC77LdjM2Lh5RM6LB/EQFRss5B64kjDDh43p24cNWxXAqdQpvVfaHvem EkSogrL/6TYgQyWAfWVfRA8mNvyvkl0fKlUJDgm7b+4bJFclkGYZHRo+cQHogqQ9DHhK v5pmEaSnTYlklgJE5msnnpDEf9aSQD32uRGD//44zsZR1/0EQD+jdH4wuLzJZhamP04E h/og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o188si5352938pgo.489.2019.05.07.06.37.46; Tue, 07 May 2019 06:38:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726658AbfEGNfd (ORCPT + 99 others); Tue, 7 May 2019 09:35:33 -0400 Received: from foss.arm.com ([217.140.101.70]:54406 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726295AbfEGNfd (ORCPT ); Tue, 7 May 2019 09:35:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9581580D; Tue, 7 May 2019 06:35:32 -0700 (PDT) Received: from queper01-lin (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 165423F73C; Tue, 7 May 2019 06:35:29 -0700 (PDT) Date: Tue, 7 May 2019 14:35:28 +0100 From: Quentin Perret To: Luca Abeni Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , "Rafael J . Wysocki" , Ingo Molnar , Peter Zijlstra , Vincent Guittot , "Paul E . McKenney" , Joel Fernandes , Luc Van Oostenryck , Morten Rasmussen , Juri Lelli , Daniel Bristot de Oliveira , Patrick Bellasi , Tommaso Cucinotta Subject: Re: [RFC PATCH 2/6] sched/dl: Capacity-aware migrations Message-ID: <20190507133528.ia4p3medvtg4z5az@queper01-lin> References: <20190506044836.2914-1-luca.abeni@santannapisa.it> <20190506044836.2914-3-luca.abeni@santannapisa.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190506044836.2914-3-luca.abeni@santannapisa.it> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Luca, On Monday 06 May 2019 at 06:48:32 (+0200), Luca Abeni wrote: > +static inline int dl_task_fit(const struct sched_dl_entity *dl_se, > + int cpu, u64 *c) > +{ > + u64 cap = (arch_scale_cpu_capacity(NULL, cpu) * arch_scale_freq_capacity(cpu)) >> SCHED_CAPACITY_SHIFT; I'm a little bit confused by this use of arch_scale_freq_capacity() here. IIUC this means you would say a big DL task doesn't fit on a big CPU just because it happens to be running at a low frequency when this function is called. Is this what we want ? If the frequency is low, we can (probably) raise it to accommodate this DL task so perhaps we should say it fits ? > + s64 rel_deadline = dl_se->dl_deadline; > + u64 rem_runtime = dl_se->dl_runtime; > + > + if (c) > + *c = cap; > + > + if ((rel_deadline * cap) >> SCHED_CAPACITY_SHIFT < rem_runtime) > + return 0; > + > + return 1; > +} Thanks, Quentin