Received: by 10.223.185.116 with SMTP id b49csp6539023wrg; Thu, 8 Mar 2018 09:03:25 -0800 (PST) X-Google-Smtp-Source: AG47ELsd/g/m4XzaHW8SNmSPQRmT8BS4EgleYDUZesW4YgznCDJrk5Si+2B0Rh+KiXNqjdaqgyHo X-Received: by 2002:a17:902:4643:: with SMTP id o61-v6mr25195884pld.103.1520528604896; Thu, 08 Mar 2018 09:03:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520528604; cv=none; d=google.com; s=arc-20160816; b=sHJkQyAvbsEpZvn8p0q31HCPhGMU9MaWGNjKe612y7iYSRhXsNfvmGE4m6ccYmWdY0 2jUnfPkl1HJgTKUsZh8ePZf4QdUpF5X18YAeYbtbC2l0qbP5Xt3z5Oz1+cpoubIOquHX aHNsN6n4ciisWTrU0+WafAdptDknKq8JA58KLz98DaXh0hxR9f7RMt1D7c2Hx3jWLD51 UfZImMBD8+4nzhOkPn8OKRdleSVdgB90eBPJv7DE5Cbv6USURFtbM0uQ1mtVOvjC0s4Z XCR3jZzAQjP0KjrAJutTTAJIlQaRN2HNUB/HdMPRtLy6dDxn+wwJU5pngZX+mA0yNGrP MNPA== 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:dmarc-filter:arc-authentication-results; bh=6oCaTssReN/w3HMeFkU9xzrsG5Ivf0+AQceaxBptrRw=; b=XslnWNi8CxtczDn60uHVzcWsG3DKGPZhTabtxacwm09qx3Nt0dDSKJEw0dMsqURdhd mGDBZOkI/ChugfZ4oTRm9wrfjqiNYYxDqw3HFF2AYDtlyLKJ1f8nSw6k2DKGJGnS80D9 8AKTF0N/KHxLqV9murmjhr2FXHnpubQ1GfaCMDJFrfRQe7tw9LyUhrX3VgoWxdXFAZaU rNPbqySLNWJE6tk3kxxAknOcH15NDWPgkaR/7Kb3dPAtdkblWdGtR3IC+ECEoux02V3V k5gnV0JXHUwG6i+9UAF4WwpSbUUvBsMRr3iyqijs8IW3uwzxv/nMuOxZ0GDJHTc2qGI+ ab3A== 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 z62si13297834pgd.688.2018.03.08.09.02.38; Thu, 08 Mar 2018 09:03:24 -0800 (PST) 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 S935817AbeCHRAZ (ORCPT + 99 others); Thu, 8 Mar 2018 12:00:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:44268 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932137AbeCHRAX (ORCPT ); Thu, 8 Mar 2018 12:00:23 -0500 Received: from localhost (i16-les03-th2-31-37-47-191.sfr.lns.abo.bbox.fr [31.37.47.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B0840208FE; Thu, 8 Mar 2018 17:00:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0840208FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=frederic@kernel.org Date: Thu, 8 Mar 2018 18:00:20 +0100 From: Frederic Weisbecker To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Peter Zijlstra , Linux PM , Thomas Gleixner , Frederic Weisbecker , Paul McKenney , Thomas Ilsche , Doug Smythies , Rik van Riel , Aubrey Li , Mike Galbraith , LKML Subject: Re: [RFC/RFT][PATCH v2 1/6] time: tick-sched: Reorganize idle tick management code Message-ID: <20180308170018.GB11118@lerouge> References: <2067762.1uWBf5RSRc@aspire.rjw.lan> <4136227.b9g9WnMbNJ@aspire.rjw.lan> <20180307231827.GA9367@lerouge> <1938066.lrFpnYERYl@aspire.rjw.lan> <20180308151407.GA11118@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 08, 2018 at 05:34:20PM +0100, Rafael J. Wysocki wrote: > On Thu, Mar 8, 2018 at 4:14 PM, Frederic Weisbecker wrote: > > On Thu, Mar 08, 2018 at 10:22:26AM +0100, Rafael J. Wysocki wrote: > >> On Thursday, March 8, 2018 12:18:29 AM CET Frederic Weisbecker wrote: > >> > On Tue, Mar 06, 2018 at 10:02:01AM +0100, Rafael J. Wysocki wrote: > >> > > Index: linux-pm/kernel/time/tick-sched.c > >> > > =================================================================== > >> > > --- linux-pm.orig/kernel/time/tick-sched.c > >> > > +++ linux-pm/kernel/time/tick-sched.c > >> > > + > >> > > +/** > >> > > + * tick_nohz_idle_prepare - prepare for entering idle on the current CPU. > >> > > + * > >> > > + * Called when we start the idle loop. > >> > > + */ > >> > > +void tick_nohz_idle_prepare(void) > >> > > +{ > >> > > + struct tick_sched *ts; > >> > > + > >> > > + __tick_nohz_idle_prepare(); > >> > > + > >> > > + local_irq_disable(); > >> > > + > >> > > + ts = this_cpu_ptr(&tick_cpu_sched); > >> > > + ts->inidle = 1; > >> > > + > >> > > + local_irq_enable(); > >> > > +} > >> > > >> > Why not calling tick_nohz_start_idle() from there? This is going to > >> > simplify the rest, you won't need to call tick_nohz_idle_go_idle() > >> > from places that don't want to stop the tick and you can then remove > >> > the stop_tick argument. > >> > >> So I guess I would then use ts->idle_entrytime as "now" in the > >> tick_nohz_get_sleep_length() computation, right? > > > > Ah right, I missed the need for ktime_get(). > > > > You can't use ts->idle_entrytime in tick_nohz_get_sleep_length() because > > full dynticks doesn't rely on it. > > > > But I think you can just do the following, with a comment explaining that > > idle_entrytime is expected to be fresh enough at this point: > > > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > > index 57b3de4..8e61796 100644 > > --- a/kernel/time/tick-sched.c > > +++ b/kernel/time/tick-sched.c > > @@ -923,7 +923,7 @@ static void __tick_nohz_idle_enter(struct tick_sched *ts, bool stop_tick) > > > > ts->idle_calls++; > > > > - expires = tick_nohz_stop_sched_tick(ts, now, cpu); > > + expires = tick_nohz_stop_sched_tick(ts, ts->idle_entrytime, cpu); > > if (expires > 0LL) { > > ts->idle_sleeps++; > > ts->idle_expires = expires; > > > > That's what I was thinking about, but ktime_get() seems to be working too. Well, ktime_get() has its share of overhead, so if we can avoid a call and use a cache...