Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3801662yba; Tue, 7 May 2019 07:19:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqyLDQRdyDIJw4pD3HlLQiaEgFVvLum1CX+XVVsNYbLfnlhZSjfCWj6FdcVrorgpY4bhaOy+ X-Received: by 2002:a65:4105:: with SMTP id w5mr404876pgp.260.1557238749928; Tue, 07 May 2019 07:19:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557238749; cv=none; d=google.com; s=arc-20160816; b=WyFzh+8jP1swr9zpt+/oEkjMj+OMmh0z+ZJe8nr/uMRqkAT4UookwFlW9hewhAPfE1 Qv0R/fBo9ZxNtN4+G5FRBBhFCRC8OfG4IwASaueKtt7nYQ9JN4s1y7/lLMXaCLciUqJk gyH8TrSFgfXsh7CnCseq3fQwchNL6untzSBzMLoK7MeMzAf/jrwzPO6fMsObfn5NLwgt j8iRJoTJukNxjRiUmURtzYRSE3hRjsHFF6hsO6oWXl1A9ja9pXWGSGljBw0MK4P7IJeD lvnoBwwtj3tij4jBW6mlr0O7M/ZsFSkcNOkomPhpJ2kJl1qO1hDUZFzFWL6KFd9srH6T mGQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=pWx4io+bMNOC7k/7Fa6xvLq5tGMRM7gm7WyP3u5XNhU=; b=bgisfkj1xAi318mQyUbl5AhOFjl3wR75E7ZSTW9KP/egM66jRt/6OihgE1Zno7qbB1 1BSJWOfr1S0KtR0WBzhDuop/b1LuP9FSyBrUxkXYNW5mI6kfSSOs4B/5i/czt6BTLm0Z hKrqgt8aj9AVw4i0DeXXRjJudogwZvxu6hSEI4ABDaeiZXzPghdQI6zDGyRmIAN0L2WJ UN3tXuLOelshOlUU+setPBkZm/atwReg8b4skrZA1XcE0Xyue2bp0KTGBI9+dIUffVf0 iwRy7kVIObPiNu5EMBQIsOfPQqPsiXPuA9OyhZ1cWX+Qh6BuOrMNwpeeyPu2TKN5WU6O 5xlA== 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 o8si4962487pgc.137.2019.05.07.07.18.51; Tue, 07 May 2019 07:19:09 -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 S1726752AbfEGORt (ORCPT + 99 others); Tue, 7 May 2019 10:17:49 -0400 Received: from ms01.santannapisa.it ([193.205.80.98]:19645 "EHLO mail.santannapisa.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726265AbfEGORt (ORCPT ); Tue, 7 May 2019 10:17:49 -0400 Received: from [83.43.182.198] (account l.abeni@santannapisa.it HELO nowhere) by santannapisa.it (CommuniGate Pro SMTP 6.1.11) with ESMTPSA id 138898218; Tue, 07 May 2019 16:17:45 +0200 Date: Tue, 7 May 2019 16:17:33 +0200 From: luca abeni To: Quentin Perret 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: <20190507161733.1a26419b@nowhere> In-Reply-To: <20190507133528.ia4p3medvtg4z5az@queper01-lin> References: <20190506044836.2914-1-luca.abeni@santannapisa.it> <20190506044836.2914-3-luca.abeni@santannapisa.it> <20190507133528.ia4p3medvtg4z5az@queper01-lin> Organization: Scuola Superiore S.Anna X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Quentin, On Tue, 7 May 2019 14:35:28 +0100 Quentin Perret wrote: > 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 ? The idea of this approach was to avoid frequency switches when possible; so, I wanted to check if the task fits on a CPU core at its current operating frequency. > If the frequency is low, we can (probably) raise it to accommodate > this DL task so perhaps we should say it fits ? In a later patch, if the task does not fit on any core (at its current frequency), the task is moved to the core having the maximum capacity (without considering the operating frequency --- at least, this was my intention when I wrote the patches :) Luca > > > + 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