From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933033AbdKPI6U (ORCPT ); Thu, 16 Nov 2017 03:58:20 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:44840 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbdKPI6L (ORCPT ); Thu, 16 Nov 2017 03:58:11 -0500 Date: Thu, 16 Nov 2017 09:58:05 +0100 (CET) From: Thomas Gleixner To: Peter Zijlstra cc: Quan Xu , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, LKML , virtualization@lists.linux-foundation.org, x86@kernel.org, xen-devel@lists.xenproject.org, Yang Zhang , Quan Xu , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Kyle Huey , Len Brown , Andy Lutomirski , Tom Lendacky , Tobias Klauser , Daniel Lezcano Subject: Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path In-Reply-To: <20171116084555.it2hqajxxd6ld5tq@hirez.programming.kicks-ass.net> Message-ID: References: <1510567565-5118-1-git-send-email-quan.xu0@gmail.com> <1510567565-5118-4-git-send-email-quan.xu0@gmail.com> <20171115121152.gqug5wzerlo3eimd@hirez.programming.kicks-ass.net> <20171116084555.it2hqajxxd6ld5tq@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Nov 2017, Peter Zijlstra wrote: > On Wed, Nov 15, 2017 at 11:03:08PM +0100, Thomas Gleixner wrote: > > If I understand the problem correctly then he wants to avoid the heavy > > lifting in tick_nohz_idle_enter() in the first place, but there is already > > an interesting quirk there which makes it exit early. > > Sure. And there are people who want to do the same for native. > > Adding more ugly and special cases just isn't the way to go about doing > that. > > I'm fairly sure I've told the various groups that want to tinker with > this to work together on this. I've also in fairly significant detail > sketched how to rework the idle code and idle predictors. > > At this point I'm too tired to dig any of that up, so I'll just keep > saying no to patches that don't even attempt to go in the right > direction. That's why I said: But lets not proliferate that. I'd rather see that go away. And yes, the VM folks should talk to those who are trying to solve similar problems for native (embedded/mobile). Thanks, tglx