Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1724082ybh; Fri, 13 Mar 2020 06:22:21 -0700 (PDT) X-Google-Smtp-Source: ADFU+vs/vXO060COmGUy6cOgF7LCZEV/lii8KoRM8VQ9obiW5DQACxOfs2Mk5owcUB7cMb8D7ZAz X-Received: by 2002:a9d:bf7:: with SMTP id 110mr11498048oth.259.1584105740950; Fri, 13 Mar 2020 06:22:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584105740; cv=none; d=google.com; s=arc-20160816; b=dmgAleQe5Zcr0wyxWpX/GGUArZQ4moEqqZpNOh/2ZWXKN/nZTAa1GPAE3HqbmR5w1/ jjF5LOlUf4O7hcW5lkslvhlf9XRHFBo4DFQx9ycQP2zrtlGbeUdbKKwoAU6BsH32+HVF C9l6+KPb+mdnpsCmvYgqfKA0pg7eJqnvJAOf57Uw61S48ALCfVD6LbBuUyhvZPYjixwj HL2U+4mDPKTCC2Hwrh+kCJPIfGV/NBPAQ+/pCpTY+9o+8Yr9ljYyE6AuMnNY0qtPkh3y HC7qpYIV5Vap6GaX95hDtI0IOD8OGjQsjuJ/3STsAhA/FYMtXw+fA9eCJJuOxgdkH+g6 nOHw== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=RJLnTnm7s04iW7LrJXTv+qyavcLzxiqAnsbMJS83S3g=; b=ACMRY3D0oMI1ljQgvUZp7zntvWBGOQaQzsOmKIE/goFME+73fAkyza5AurqhCARGwl s0CRWBJQgl0x0/RQw753bh3bcWdDZKmT1punWCHXZNmY31O6YcnZzF1g6g5iCe9VudOg bLBOTBDh4AeX2t2z9s9m20PK7gY5FnRH59B9EEHqX+qRXE011uJI/Gsw5PdM0fbqiDpX p6689YFcD27P3Nc/0w429lD5ll19Y2lpw+LynZNXm3KhrVwSD2GIExbacOLelgCB1L2b hJsGkskZPy7pfJUAoGG55udEj0tVbY3NIN4W8xDcLmKn7u+jyX9Z2UlRGn8SEUH5Nn/Q nhug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Mz/40O3M"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w73si4058720oiw.206.2020.03.13.06.22.03; Fri, 13 Mar 2020 06:22:20 -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; dkim=pass header.i=@linaro.org header.s=google header.b="Mz/40O3M"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726729AbgCMNVQ (ORCPT + 99 others); Fri, 13 Mar 2020 09:21:16 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:38999 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726659AbgCMNVQ (ORCPT ); Fri, 13 Mar 2020 09:21:16 -0400 Received: by mail-lj1-f195.google.com with SMTP id f10so10482192ljn.6 for ; Fri, 13 Mar 2020 06:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RJLnTnm7s04iW7LrJXTv+qyavcLzxiqAnsbMJS83S3g=; b=Mz/40O3Mx7TdmfcBvwwu9RMoDrLqwnVjTPMYE47Srzdebk24tCWbcU3QwxNiEgbIZe FLzTBRQSzx90vg36icDMO7NafRQ/Tx5//800cXxFOt4ne5yIBSlxtIf8jS4zuOAdJ0a5 mHMkhbbBRUK3GCXNZhymDIIAPRRiH9Zgtr39+EqDb/2ImYthNs53LcK99QRliW2eY/DO hRHZm5fUc6++gIdeECY61EbTHHM77+TMCF6TxLtsmBNcNhZsWXrD9cE3VeqNyjDfIOYS fDK2kdYq1aR+OYmacB6WueRd/DF550WX1x/O9LTquNpMS7uu3YLpZOosf2HW/sifLgms O/jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RJLnTnm7s04iW7LrJXTv+qyavcLzxiqAnsbMJS83S3g=; b=Xdzv4OsfX5Zw+gYgqH7O2kvw2+LTMWeemjimXmy+Xf9BFoD+ZdTasRV+a4xPDnGko1 HErcbzh1wjXOco1HomhRJeONQulaUzdmSN5ruRKX3YCE08A9hFt0a0nvtz8IfGMNEYDn xt0ZBi14FYBQ3uETi491XsGt3r9x2X5WPZ+0eFzU5GKa8oE/rx4dzWr61sdq0SmYo4Ho LigruswopwUlmNH5bY+7oH4KKsOuzOLlx2nY90M9hc+vDSpIiC0ZlQ1Dp4tfpS3iaVhL WLMleMc9C/o49/jGiCJnTIOzIYRnpy68KX5znBpZqrLdr/MFFQgvyO6+LTA6dcbdCllI ixKw== X-Gm-Message-State: ANhLgQ0xyLadKR6BtsDMGDdFJyc2iAQC/hdzCAClF8x2eiS9iBx7hdcv VdXdNm51632GnsdgEprEI1rgAgHTegAqBEeYltDVFg== X-Received: by 2002:a2e:8112:: with SMTP id d18mr8088951ljg.137.1584105673499; Fri, 13 Mar 2020 06:21:13 -0700 (PDT) MIME-Version: 1.0 References: <20200311202625.13629-1-daniel.lezcano@linaro.org> In-Reply-To: From: Vincent Guittot Date: Fri, 13 Mar 2020 14:21:02 +0100 Message-ID: Subject: Re: [PATCH V2] sched: fair: Use the earliest break even To: Daniel Lezcano Cc: Peter Zijlstra , Ingo Molnar , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , linux-kernel , Qais Yousef , Valentin Schneider Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Mar 2020 at 14:17, Daniel Lezcano wr= ote: > > On 13/03/2020 14:15, Vincent Guittot wrote: > > On Fri, 13 Mar 2020 at 13:15, Daniel Lezcano wrote: > > [ ... ] > > >>>>>> + > >>>>>> + if (idle_state) > >>>>>> + idle_set_break_even(rq, ktime_get_ns() + > >>>>> > >>>>> What worries me a bit is that it adds one ktime_get call each time = a > >>>>> cpu enters idle > >>>> > >>>> Right, we can improve this in the future by folding the local_clock(= ) in > >>>> cpuidle when entering idle with this ktime_get. > >>> > >>> Using local_clock() would be more latency friendly > >> > >> Unfortunately we are comparing the deadline across CPUs, so the > >> local_clock() can not be used here. > >> > >> But if we have one ktime_get() instead of a local_clock() + ktime_get(= ), > >> that should be fine, no? > > > > Can't this computation of break_even be done in cpuidle framework > > while computing other statistics for selecting the idle state instead > > ? cpuidle already uses ktime_get for next hrtimer as an example. > > So cpuidle compute break_even and make it available to scheduler like > > exit_latency. And I can imagine that system wide time value will also > > be needed when looking at next wakeup event of cluster/group of CPUs > > Ok, so you suggest to revisit and consolidate the whole time capture in > cpuidle? I think that makes sense. Yes > > > -- > Linaro.org =E2=94=82 Open source software for A= RM SoCs > > Follow Linaro: Facebook | > Twitter | > Blog >