From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934056AbdKPJMx (ORCPT ); Thu, 16 Nov 2017 04:12:53 -0500 Received: from mail-ot0-f195.google.com ([74.125.82.195]:45414 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933712AbdKPJMj (ORCPT ); Thu, 16 Nov 2017 04:12:39 -0500 X-Google-Smtp-Source: AGs4zMYIMB74FqfUo222HWY55o0sMD37sJ+TevcOcRDWvVuTLt7zVyhpJ7vlwfXZnUX3c+Odwlz9Gg== Subject: Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path To: Thomas Gleixner , 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 , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Kyle Huey , Len Brown , Andy Lutomirski , Tom Lendacky , Tobias Klauser , Daniel Lezcano 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> From: Quan Xu Message-ID: <46086489-5a01-16e1-9314-70ae53c01952@gmail.com> Date: Thu, 16 Nov 2017 17:12:28 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-11-16 06:03, Thomas Gleixner wrote: > On Wed, 15 Nov 2017, Peter Zijlstra wrote: > >> On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote: >>> From: Yang Zhang >>> >>> Implement a generic idle poll which resembles the functionality >>> found in arch/. Provide weak arch_cpu_idle_poll function which >>> can be overridden by the architecture code if needed. >> No, we want less of those magic hooks, not more. >> >>> Interrupts arrive which may not cause a reschedule in idle loops. >>> In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry >>> for interrupts and VM-exit immediately. Also this becomes more >>> expensive than bare metal. Add a generic idle poll before enter >>> real idle path. When a reschedule event is pending, we can bypass >>> the real idle path. >> Why not do a HV specific idle driver? > 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. See commit > 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this commit > looks similar. But lets not proliferate that. I'd rather see that go away. agreed. Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu") in kvm guest. I won't proliferate that.. > But the irq_timings stuff is heading into the same direction, with a more > complex prediction logic which should tell you pretty good how long that > idle period is going to be and in case of an interrupt heavy workload this > would skip the extra work of stopping and restarting the tick and provide a > very good input into a polling decision. interesting. I have tested with IRQ_TIMINGS related code, which seems not working so far. Also I'd like to help as much as I can. > This can be handled either in a HV specific idle driver or even in the > generic core code. If the interrupt does not arrive then you can assume > within the predicted time then you can assume that the flood stopped and > invoke halt or whatever. > > That avoids all of that 'tunable and tweakable' x86 specific hackery and > utilizes common functionality which is mostly there already. here is some sample code. Poll for a while before enter halt in cpuidle_enter_state() If I get a reschedule event, then don't try to enter halt.  (I hope this is the right direction as Peter mentioned in another email) --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c @@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,                 target_state = &drv->states[index];         } +#ifdef CONFIG_PARAVIRT +       paravirt_idle_poll(); + +       if (need_resched()) +               return -EBUSY; +#endif +         /* Take note of the planned idle state. */         sched_idle_set_state(target_state); thanks, Quan Alibaba Cloud