Received: by 10.213.65.68 with SMTP id h4csp3473470imn; Tue, 3 Apr 2018 05:42:08 -0700 (PDT) X-Google-Smtp-Source: AIpwx48bpUdi/GgvNN2FpRbvsMj0UOdfynA9sRWVHYY+FFHpFGSmrbGT4lBS3N1nCGpHG2qh1yue X-Received: by 10.98.139.143 with SMTP id e15mr10533533pfl.134.1522759328696; Tue, 03 Apr 2018 05:42:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522759328; cv=none; d=google.com; s=arc-20160816; b=RdQJn5/DRCFRGgfLUYg2biPLpYq/PGo49LYMe52D3PQlpY8kr4ZQa77AvEuc0JfSsP WGZxNy3jW23yZgUYl3ZgANkea3Glj3nAMcfk01wics6E6+sycOzNZ0Wmi2xXT0A6b9L1 BKbZFU7nCrLLatx+sWxgwWDtDyaYs9D6rlsQoswXQ8BhKRCvJHMKF9PcY2ukGyevfP2v aAy+2HKcmHA3Q0DzFEfhaG7ZV6WIhBQfFBsZA+bUamT4ngqKYJvk59XOSMxLMvwV0Y5Y +Z8dg+biaIMkGQvSZo1szw1rwkc1HzZuDiUpncnB0b9ELwVxR/VP8iQVbs4fah2PVWor GUYQ== 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:dkim-signature:arc-authentication-results; bh=hpR0JYX6kCN4fehOmbzfn0y9cBwksNUzAiogoxOo9Mg=; b=07sCLJXZ8Dsm4RCIX9M+oQhyRhVayGkjicFfJkfNKgA8O/yx6CTr/KFq95zPhSaJ36 ZwyZXpMw+Ly+NF6YknrGKkDNB2Oi4OlebZI0idu2u7v6n0th/rOquaig9ALZSdg0/u82 NXqPU5fQk5+BrfcG33jgZMqAHnAUrkwXA7BbQwqNG6ZQnX9uV0wh+TroimoUICSE4mV5 pYsiAxEv0jEtS8+XnAhivEfluIBAdroBhZN3ywCH5TVuAmWXJUMKZtE9b/7r2Gqb3g9V QcvH+1pMdklbyCo9VC0pD106UzvxomRvA3O+Rmnepq3BqgOYZfpWek9etipXkgbp4r3T xwBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeblueprint-co-uk.20150623.gappssmtp.com header.s=20150623 header.b=DRwaUp5r; 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 n13si2111898pfg.227.2018.04.03.05.41.54; Tue, 03 Apr 2018 05:42:08 -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=@codeblueprint-co-uk.20150623.gappssmtp.com header.s=20150623 header.b=DRwaUp5r; 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 S932197AbeDCMjx (ORCPT + 99 others); Tue, 3 Apr 2018 08:39:53 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:43867 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932087AbeDCMjv (ORCPT ); Tue, 3 Apr 2018 08:39:51 -0400 Received: by mail-wr0-f193.google.com with SMTP id p53so18582767wrc.10 for ; Tue, 03 Apr 2018 05:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeblueprint-co-uk.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hpR0JYX6kCN4fehOmbzfn0y9cBwksNUzAiogoxOo9Mg=; b=DRwaUp5rWz//uFcMjueMv3cQ8KLZdBOmycZD3FP8TQJo+DlfD7+/7fpFh+6S4+/rix eQ7kw6QXZcqnUA5DYJ1O9yLegsiiRKPBblDNCg8raNQyyVnNfnQHoXXwPhWWQASq00yK wBoa/QqCcbPfO+y2LwxviunEMUrxJg0EizPi4MuwYhV3+0zJwvi/UDK0nR0tX43KHU6s oyhihWaCb+OUHgtCihxWdxldgfZT6FRpHEhIQZwgdwy9nmDGi0pgo/5RzOdYuGLXIZHu A4avCvwsQXvZV8KMVqBggVl5D1CwvcOoy1XvVUlbtUZGDqgjJEAOtsW6c7vFpDOoD+Cv el/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hpR0JYX6kCN4fehOmbzfn0y9cBwksNUzAiogoxOo9Mg=; b=gtbcHOv7jDkl2j6irdLrr7DkRkJyjJgDv9yPstLC4UJaGDFGzHJl/RN4sBNPPmhmSo s/vlHjupfahYh0c3lmlsmBk2Uorxs/tDw0wKTL9stCMvtQaHqb2COVHu+6lcBzQpX4kE HDKbFN+IhYzirB7BjN8qBPlWL/uRdPWrjZeioqZTFO9naU43cfcoxxu+SvyRATDze9uj +2VD4QO7l1c05FlUxvXpWt+Jt2HnMQzQnI5XVP59CawyOzEjhHHKZ5ORczoOu0wtXkbf f4Gl2jjpl5ve3Z27UL0OaneG6OSMml9dHQgqXOoC/iyk8ZS/CrQBT7bIFNlRMtUc8hsL 1fMQ== X-Gm-Message-State: AElRT7HMmVRirOFazQfkNk8zujs7J+CRo9Z20ptNI29HjASxGHASLxxo 9yKmFAhiTba2em7UF2YDmD4lvA== X-Received: by 10.223.220.70 with SMTP id m6mr9486203wrj.244.1522759190654; Tue, 03 Apr 2018 05:39:50 -0700 (PDT) Received: from localhost ([94.13.103.247]) by smtp.gmail.com with ESMTPSA id c187sm792599wmf.18.2018.04.03.05.39.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 05:39:50 -0700 (PDT) Date: Tue, 3 Apr 2018 13:39:48 +0100 From: Matt Fleming To: Davidlohr Bueso Cc: peterz@infradead.org, mingo@kernel.org, efault@gmx.de, rostedt@goodmis.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning Message-ID: <20180403123948.GA4771@codeblueprint.co.uk> References: <20180402164954.16255-1-dave@stgolabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180402164954.16255-1-dave@stgolabs.net> User-Agent: Mutt/1.5.24+42 (6e565710a064) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 02 Apr, at 09:49:54AM, Davidlohr Bueso wrote: > > We can get rid of it be the "traditional" means of adding an update_rq_clock() call > after acquiring the rq->lock in do_sched_rt_period_timer(). > > The case for the rt task throttling (which this workload also hits) can be ignored in > that the skip_update call is actually bogus and quite the contrary (the request bits > are removed/reverted). By setting RQCF_UPDATED we really don't care if the skip is > happening or not and will therefore make the assert_clock_updated() check happy. > > Signed-off-by: Davidlohr Bueso > --- > kernel/sched/rt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c > index 86b77987435e..ad13e6242481 100644 > --- a/kernel/sched/rt.c > +++ b/kernel/sched/rt.c > @@ -839,6 +839,8 @@ static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun) > continue; > > raw_spin_lock(&rq->lock); > + update_rq_clock(rq); > + > if (rt_rq->rt_time) { > u64 runtime; Looks good to me. Reviewed-by: Matt Fleming