Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp47645ybt; Thu, 18 Jun 2020 17:52:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvMqwZFOrw1yHoFNC1/xNdpF4GwCtI6gQ8X6fgbQ0oXaqyYGwmAVEyXSxkurxfpMVndSst X-Received: by 2002:aa7:d5c7:: with SMTP id d7mr856613eds.11.1592527957353; Thu, 18 Jun 2020 17:52:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592527957; cv=none; d=google.com; s=arc-20160816; b=wkm5JU0v9AM4a21Xvh4TCApI+X5Dncy1xU3bYruxpefi3Ipc03jTUrAwGffKKWSSO4 EzrJgpwCKt+TNrHjy5xjiXiKFd/czKisuSz3lrMW0EGMyeVyon4zo+wGU6R2nP+DR1TI lhDgta2n9mMiS4Ame6gSaekOtD/FpaBmNh6ujmzfM6zbkBKG91vTmS5997wbFdRV3PSk zQbGI1UcQWA47Y17wUdOIjIJY9sT4zasfR4Vohe5O1ykyYFDLRvziKtaKwGY2dRUSsaF nr2SXdUzCBDjh2PiSMHQ41t8ziHxr5qre81LMp9xWI45RhOKA6/9TQoS3FEJh3M4q0qf sbyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=FQEeRFx60IswzJRvFAoxOWsQup+koH/QTgmv5jgsGbM=; b=ZZGdkxZsi+qsSQGKmfFwgGHO6K0g6GONyG0FqmZO+MWun/EbTtzofCwC83bOg0dKK+ F9jIJ09V+iiHDP01EQJtcb4HMxqDV86j6yUhhKOoCZw5xs1dmI/XvoqP81X+rv/vwVUq Gxrmzj6RFRcd3k75wrVK7CGwhhOAbsXWJgXzsd4GRpKwyjilkUk3wQfEHbA+B73dQNlf idzZYYBgaYQ/eXFEhBjm4JzJYa/O7a5WvSNBCCeHR5ubd6wNCx7p4IsNGnAZY2xGOZDv Jmnay/lHsLzitDbtKHe6UVdrO67L5klWlfucvSzAUul37TyM1xhPv3/wJQI3QDdlNc/g 4pFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=PpoEAonn; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k1si2850912eja.313.2020.06.18.17.52.14; Thu, 18 Jun 2020 17:52:37 -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=@chromium.org header.s=google header.b=PpoEAonn; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728125AbgFRVSm (ORCPT + 99 others); Thu, 18 Jun 2020 17:18:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726835AbgFRVSj (ORCPT ); Thu, 18 Jun 2020 17:18:39 -0400 Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75A34C06174E for ; Thu, 18 Jun 2020 14:18:39 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id o2so4427571vsr.0 for ; Thu, 18 Jun 2020 14:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FQEeRFx60IswzJRvFAoxOWsQup+koH/QTgmv5jgsGbM=; b=PpoEAonnGJ7mXYvMQg/Jlo7Be9y71VSwHLqCWGfv9iU/PZlToBKeT8joOW5WjJrPN0 046R9USAk28DraDmv99PnQ9cs+Oyijgm8cxSOxmJ0U+hb3TZG2e42GFJhKAzG06zmyrL I1LZZFuvveh4bRMNkTSSFef/D+iVOqjnxZWyk= 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; bh=FQEeRFx60IswzJRvFAoxOWsQup+koH/QTgmv5jgsGbM=; b=Y/TPr93/kXFkOM2adTBgIcu3J1Hf/oj9JvvSE6D9iY8HRIn8oND4/GPPQwmn56mqVb nsdv71qEvgzl7WcScUiGCLrs+WBjFNdGW2PTULlUywOHlfcpf8huXb+SW2UHue54obwr SHm72yPMlDfsUVLVJV0q44EFK2oRaux3BDI/lYbePBssmcpCQPEJZUEYq5zZ8tDiq8gv mCGXDRhP3JpWJnQA1ifUfFbdwgG+4X/DZirpTkUWEFletmdRh0lev0jeOBQAlh9kyB4G w10tO+CCH7qlq1tPRpuUUZV4aqUi6o1R47OfMVPmORzGzmnOC0Ovg68c86VEDu7pzssV u8ig== X-Gm-Message-State: AOAM530dgB6xCYUBLKGvFNlgJCEbhe+jF5nay1Hs0q9+fSqhcw4Ck6Kh uKjyst3V8J/CD/dC1+2HXnBZE3GZ+pg= X-Received: by 2002:a67:db88:: with SMTP id f8mr5198615vsk.165.1592515118187; Thu, 18 Jun 2020 14:18:38 -0700 (PDT) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com. [209.85.217.45]) by smtp.gmail.com with ESMTPSA id 4sm331589uae.4.2020.06.18.14.18.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2020 14:18:36 -0700 (PDT) Received: by mail-vs1-f45.google.com with SMTP id u17so4409717vsu.7 for ; Thu, 18 Jun 2020 14:18:35 -0700 (PDT) X-Received: by 2002:a67:e445:: with SMTP id n5mr5244712vsm.73.1592515114671; Thu, 18 Jun 2020 14:18:34 -0700 (PDT) MIME-Version: 1.0 References: <20200610151818.1.I666ecd9c6f3c6405bd75831a21001b8109b6438c@changeid> <20200612125250.7bwjfnxhurdf5bwj@e107158-lin.cambridge.arm.com> In-Reply-To: <20200612125250.7bwjfnxhurdf5bwj@e107158-lin.cambridge.arm.com> From: Doug Anderson Date: Thu, 18 Jun 2020 14:18:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq To: Qais Yousef Cc: Benson Leung , Enric Balletbo i Serra , hsinyi@chromium.org, Joel Fernandes , Peter Zijlstra , Nicolas Boichat , Gwendal Grignou , Quentin Perret , ctheegal@codeaurora.org, Guenter Roeck , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Jun 12, 2020 at 5:52 AM Qais Yousef wrote: > > On 06/10/20 15:18, Douglas Anderson wrote: > > The cros_ec_spi driver is realtime priority so that it doesn't get > > preempted by other taks while it's talking to the EC but overall it > > really doesn't need lots of compute power. Unfortunately, by default, > > the kernel assumes that all realtime tasks should cause the cpufreq to > > jump to max and burn through power to get things done as quickly as > > possible. That's just not the correct behavior for cros_ec_spi. > > > > Switch to manually overriding the default. > > > > This won't help us if our work moves over to the SPI pump thread but > > that's not the common code path. > > > > Signed-off-by: Douglas Anderson > > --- > > NOTE: This would cause a conflict if the patch > > https://lore.kernel.org/r/20200422112831.870192415@infradead.org lands > > first > > > > drivers/platform/chrome/cros_ec_spi.c | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/platform/chrome/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c > > index debea5c4c829..76d59d5e7efd 100644 > > --- a/drivers/platform/chrome/cros_ec_spi.c > > +++ b/drivers/platform/chrome/cros_ec_spi.c > > @@ -709,8 +709,11 @@ static void cros_ec_spi_high_pri_release(void *worker) > > static int cros_ec_spi_devm_high_pri_alloc(struct device *dev, > > struct cros_ec_spi *ec_spi) > > { > > - struct sched_param sched_priority = { > > - .sched_priority = MAX_RT_PRIO / 2, > > + struct sched_attr sched_attr = { > > + .sched_policy = SCHED_FIFO, > > + .sched_priority = MAX_RT_PRIO / 2, > > + .sched_flags = SCHED_FLAG_UTIL_CLAMP_MIN, > > + .sched_util_min = 0, > > Hmm I thought Peter already removed all users that change RT priority directly. > > https://lore.kernel.org/lkml/20200422112719.826676174@infradead.org/ Yeah, I mentioned that patch series "after the cut" in my patch and also made sure to CC Peter on my patch. I'm not sure what happened to that series since I don't see it in linuxnext... > > }; > > int err; > > > > @@ -728,8 +731,7 @@ static int cros_ec_spi_devm_high_pri_alloc(struct device *dev, > > if (err) > > return err; > > > > - err = sched_setscheduler_nocheck(ec_spi->high_pri_worker->task, > > - SCHED_FIFO, &sched_priority); > > + err = sched_setattr_nocheck(ec_spi->high_pri_worker->task, &sched_attr); > > if (err) > > dev_err(dev, "Can't set cros_ec high pri priority: %d\n", err); > > return err; > > If I read the code correctly, if you fail here cros_ec_spi_probe() will fail > too and the whole thing will not be loaded. If you compile without uclamp then > sched_setattr_nocheck() will always fail with -EOPNOTSUPP. Oops, definitely need to send out a v2 for that if nothing else. Is there any good way for me to code this up or do I need a big #ifdef somewhere in my code? > Why can't you manage the priority and boost value of such tasks via your init > scripts instead? I guess I feel like it's weird in this case. Userspace isn't creating this task and isn't the one marking it as realtime. ...and, if we ever manage to upgrade the protocol which we use to talk to the EC we might fully get rid of this task the need to have something boosted up to realtime. Said another way: the fact that we even have this task at all and the fact that it's realtime is an implementation detail of the kernel. It seems really weird to add initscripts for it. > I have to admit I need to think about whether it makes sense to have a generic > API that allows drivers to opt-out of the default boosting behavior for their > RT tasks. Seems like it would be useful. -Doug