Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp4358069ybh; Tue, 6 Aug 2019 10:16:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqwA0617Axc+lVv9tkR8rvfe//MvR2JK1aELh8Wv6/EzMe85QcJTkkv0G+sOVVp0hZ47jl X-Received: by 2002:a17:902:e40f:: with SMTP id ci15mr4221759plb.103.1565111769173; Tue, 06 Aug 2019 10:16:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565111769; cv=none; d=google.com; s=arc-20160816; b=lo7t6g9pCF7O4dk0CRUANnB1/U/fUr6dW7KQCG6Yt9ySFKYtG8pYHN671rCuNsTfBe P4BW/GlnoHCFMNbTkjBnFOe7JnrdqCJt/ifxRDIxddhQ13KqxPvNgPIQADN9pxSmjmdh +ldmTaLRUEMmML53q2R2B92JpM5Duc5Zm73vgbhuM3CAN8dQMKXVu2YsOtorw2MNvPL+ ZOPYM/f/CpwyqdTUvfOi+t4taTit0T3TXc3a0tYi9ysCXoaxXksEeECJmAfZxtJy3E47 P7kog4UxOwp3gAoSiO9K/4rHejHm1f4REQUJIkbGj+gUW5XoIZAvuqw2UadBQ3rp9Uc/ HHWw== 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=a3u6Iiw4BPf1RARgZ81i925P1Jgxiov+FHc8IbMfKkU=; b=TCmYdXvK5446x5ZABl1DOYkBRm0fk6NK4DerCYEO9WcNK3ChuKqUi0qXDlKLEK9U5Z SgA6JcCP5ckMEsAa30H+Y1Roe53fJA8hdjz6EaeJnFiQl/56XY/rgtz6/Yl892NLizsQ as2y99qIZSpviJOPfiA/UMWW5v8PJm9tsCrsphfk45ITA/hQWcl8GzNC9lmyvvhfPqfH Glkudzf5Rg5RciAlk0OF3MSy1dURQX8XMJBO+KFhI8wO+H1EAUxDWJYrxZCY5B2dUe21 FNIwlCQfYpVc9LiFuuWqw+NDJCS6QCLh1SZtScMx1UpOiX9347rrj7L3oNjPunyZMh76 xdtA== 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 e19si15044826pjp.49.2019.08.06.10.15.53; Tue, 06 Aug 2019 10:16: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 S2387829AbfHFQMA (ORCPT + 99 others); Tue, 6 Aug 2019 12:12:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:39912 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387822AbfHFQL7 (ORCPT ); Tue, 6 Aug 2019 12:11:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A19EAAC90; Tue, 6 Aug 2019 16:11:57 +0000 (UTC) Date: Tue, 6 Aug 2019 18:11:53 +0200 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, cgroups@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan , Alessio Balsini Subject: Re: [PATCH v13 2/6] sched/core: uclamp: Propagate parent clamps Message-ID: <20190806161153.GA19991@blackbody.suse.cz> References: <20190802090853.4810-1-patrick.bellasi@arm.com> <20190802090853.4810-3-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20190802090853.4810-3-patrick.bellasi@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 02, 2019 at 10:08:49AM +0100, Patrick Bellasi wrote: > @@ -7095,6 +7149,7 @@ static ssize_t cpu_uclamp_write(struct kernfs_open_= file *of, char *buf, > if (req.ret) > return req.ret; > =20 > + mutex_lock(&uclamp_mutex); > rcu_read_lock(); > =20 > tg =3D css_tg(of_css(of)); > @@ -7107,7 +7162,11 @@ static ssize_t cpu_uclamp_write(struct kernfs_open= _file *of, char *buf, > */ > tg->uclamp_pct[clamp_id] =3D req.percent; > =20 > + /* Update effective clamps to track the most restrictive value */ > + cpu_util_update_eff(of_css(of)); > + > rcu_read_unlock(); > + mutex_unlock(&uclamp_mutex); Following my remarks to "[PATCH v13 1/6] sched/core: uclamp: Extend CPU's cgroup", I wonder if the rcu_read_lock() couldn't be moved right before cpu_util_update_eff(). And by extension rcu_read_(un)lock could be hidden into cpu_util_update_eff() closer to its actual need. --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE+amhwRV4jZeXdUhoK2l36XSZ9y4FAl1JpsAACgkQK2l36XSZ 9y59yRAAiTIJ7zMA4BzWiApDiPUuWBsjGzn3EGAI1lHOu3FP0ILzIJMvHZqRChjv uENYySwWcX1WMTDdya+T2DlQFgMnmmaoDhfUQsP2WjtFsGgO/2w4iCW+V7E0pfLX KvYmqSnzd84pGJ13PPlJlaaFtftIPOZSroK9Ne/Qdze8W8NkcyF5EXxEZ1jDYK2Z OuzOuCTkSfX+G76pZnRkdq+GpomApHpke1Ps4oAYwHfattL2KCum9tNZ1abC2BtO D9Vstb553sIGcNlV70QsIMO5mCS3v7zdZZE+K86watSuy0yYBq+HarnbYNTzhGdU 7ZQQ6eB+386+jlPinpVwxdu07ZkScZzQmrBMV8IBDyPcSGAj4HreGu/AE/MFKn1u GuxhhfbvAolvJCO2XxFrko9l1aUAHXOflCEs1Mm2FKvYqYkWG++v2YOSQTFIVhy3 +ZSKSWXeKjSL+rz+FUaEiPzmZrZRNowJfNWNNGBNCFWlyXvXmSVxdXyPs6oJcHI2 t+cCXvdlkUSVYBBlmivh1+ZizXw4RDCh1Vw8yU9Wl5jN+wcOgb/fGfYUeVs+ciDA hQu+K9hybv1dJrxs9qAbY8vqtZoxxOy5w2XzgyKP1Gg3TevAmVJMcvwE6A1aPd4+ FH0Q0/bjPIDdH2gbWeSa2e3oJXWuVSLBrSLo5nUFFMIY/eTX7WI= =I3Ys -----END PGP SIGNATURE----- --gKMricLos+KVdGMg--