Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751111AbdCONV1 (ORCPT ); Wed, 15 Mar 2017 09:21:27 -0400 Received: from mail-vk0-f42.google.com ([209.85.213.42]:34158 "EHLO mail-vk0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751280AbdCONUa (ORCPT ); Wed, 15 Mar 2017 09:20:30 -0400 MIME-Version: 1.0 In-Reply-To: <20170315112020.GA18557@e110439-lin> References: <1488292722-19410-1-git-send-email-patrick.bellasi@arm.com> <1488292722-19410-2-git-send-email-patrick.bellasi@arm.com> <20170315112020.GA18557@e110439-lin> From: Joel Fernandes Date: Wed, 15 Mar 2017 06:20:28 -0700 Message-ID: Subject: Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller To: Patrick Bellasi Cc: "Joel Fernandes (Google)" , Linux Kernel Mailing List , linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , Paul McKenney Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1582 Lines: 40 On Wed, Mar 15, 2017 at 4:20 AM, Patrick Bellasi wrote: > On 13-Mar 03:46, Joel Fernandes (Google) wrote: >> On Tue, Feb 28, 2017 at 6:38 AM, Patrick Bellasi >> wrote: >> > The CPU CGroup controller allows to assign a specified (maximum) >> > bandwidth to tasks within a group, however it does not enforce any >> > constraint on how such bandwidth can be consumed. >> > With the integration of schedutil, the scheduler has now the proper >> > information about a task to select the most suitable frequency to >> > satisfy tasks needs. >> [..] >> >> > +static u64 cpu_capacity_min_read_u64(struct cgroup_subsys_state *css, >> > + struct cftype *cft) >> > +{ >> > + struct task_group *tg; >> > + u64 min_capacity; >> > + >> > + rcu_read_lock(); >> > + tg = css_tg(css); >> > + min_capacity = tg->cap_clamp[CAP_CLAMP_MIN]; >> >> Shouldn't the cap_clamp be accessed with READ_ONCE (and WRITE_ONCE in >> the write path) to avoid load-tearing? > > tg->cap_clamp is an "unsigned int" and thus I would expect a single > memory access to write/read it, isn't it? I mean: I do not expect the > compiler "to mess" with these accesses. This depends on compiler and arch. I'm not sure if its in practice these days an issue, but see section on 'load tearing' in Documentation/memory-barriers.txt . If compiler decided to break down the access to multiple accesses due to some reason, then might be a problem. Adding Paul for his expert opinion on the matter ;) Thanks, Joel