From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933932AbdKPIq3 (ORCPT ); Thu, 16 Nov 2017 03:46:29 -0500 Received: from merlin.infradead.org ([205.233.59.134]:56908 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932446AbdKPIqU (ORCPT ); Thu, 16 Nov 2017 03:46:20 -0500 Date: Thu, 16 Nov 2017 09:45:55 +0100 From: Peter Zijlstra To: Thomas Gleixner 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 Message-ID: <20171116084555.it2hqajxxd6ld5tq@hirez.programming.kicks-ass.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.