Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp504406ybe; Wed, 4 Sep 2019 03:18:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwNzwaLhUbmurEU6VD6k6nb/boK+54MfYrzmd6jFITMxaBh6UANZkqotkYbkWrl8swt5AhQ X-Received: by 2002:a17:90a:1c01:: with SMTP id s1mr1089599pjs.76.1567592324319; Wed, 04 Sep 2019 03:18:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567592324; cv=none; d=google.com; s=arc-20160816; b=Wzn6Lemd5xBfcZ+1pxWYj+55iY4RO5ULKOqrvl1d9bQ+OMMV4jUjlwcxdYEgq3bemJ FddRnYvIMzWwMCEo9XxOIScTsK5Tb2d8wPaqUQJAge8o1mOEF37oIdGm7QZd4SG9Z7Uo FB5j8rYcnmTs+HwGUIwFekPUkd0Lyu1jro6R5G2XcnIAgRA2RV9uCQGIo0iULGx88mdt 2+LsKXlPZYnbJLMtwE5Nl6rZ7N7QrOuLHEYI5eB2rUZs0f9YkLilFpGyAonP9Xtb5nbL phbnKvcAMaKqKaISr4nA7PyFPlIP2UG7C7TVeYH8qzan0/IJfEX/0JhPz+CJvKD5nYOZ QJpg== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=+zteeQRgpqm0MkSesWHn3sorGKWT1f/tp+6B+PArn7w=; b=Z4316WqKw4/Z9L6C9lsfKw0Li25rWqRCEAter4Z4yZ8rFBslxtMC9ntlw/FhSFMLmq FreAISZsiGeVhB/rKkj8j5ZCQkVwi8tuOzAokpvK0Zorkqh0zFO3xoMkbBJrwGW45RXm k4B9swInwCFAMO0yiPIh8PrY//6Z+OdYDsxuRjkN2xRDYAp7TtA4ken7thMexD6XKu5t 0YFgIz1j2z+Rj3oUtFdGe3elWkvu8zOY3D4cG4SVneHapUdJZhmVKX3NsDCOZE4MDzWZ IxO5WPAv1YoL0ii8KzjoCk+Jv9pUBXDUYuPsIs4Zr3F2xWUrt3paw1ixMfWLdgttHrT+ q0bQ== 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 36si17277945pld.289.2019.09.04.03.18.29; Wed, 04 Sep 2019 03:18:44 -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 S1728238AbfIDKQZ (ORCPT + 99 others); Wed, 4 Sep 2019 06:16:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:42742 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725840AbfIDKQY (ORCPT ); Wed, 4 Sep 2019 06:16:24 -0400 Received: from oasis.local.home (bl11-233-114.dsl.telepac.pt [85.244.233.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF72E21881; Wed, 4 Sep 2019 10:16:20 +0000 (UTC) Date: Wed, 4 Sep 2019 06:16:16 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Alessio Balsini , mingo@kernel.org, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com, luca.abeni@santannapisa.it, bristot@redhat.com, dvyukov@google.com, tglx@linutronix.de, vpillai@digitalocean.com, kernel-team@android.com Subject: Re: [RFC][PATCH 01/13] sched/deadline: Impose global limits on sched_attr::sched_period Message-ID: <20190904061616.25ce79e1@oasis.local.home> In-Reply-To: <20190902091623.GQ2349@hirez.programming.kicks-ass.net> References: <20190726145409.947503076@infradead.org> <20190726161357.397880775@infradead.org> <20190802172104.GA134279@google.com> <20190805115309.GJ2349@hirez.programming.kicks-ass.net> <20190822122949.GA245353@google.com> <20190822165125.GW2369@hirez.programming.kicks-ass.net> <20190831144117.GA133727@google.com> <20190902091623.GQ2349@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (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 On Mon, 2 Sep 2019 11:16:23 +0200 Peter Zijlstra wrote: > in sched_dl_period_handler(). And do: > > + preempt_disable(); > max = (u64)READ_ONCE(sysctl_sched_dl_period_max) * NSEC_PER_USEC; > min = (u64)READ_ONCE(sysctl_sched_dl_period_min) * NSEC_PER_USEC; > + preempt_enable(); Hmm, I'm curious. Doesn't the preempt_disable/enable() also add compiler barriers which would remove the need for the READ_ONCE()s here? -- Steve