From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751116AbdKTHFR (ORCPT ); Mon, 20 Nov 2017 02:05:17 -0500 Received: from mail-ot0-f196.google.com ([74.125.82.196]:33502 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751049AbdKTHFO (ORCPT ); Mon, 20 Nov 2017 02:05:14 -0500 X-Google-Smtp-Source: AGs4zMZK4nw9hmHL38EHIYuxcYUTK8TPqYT5yYYeJ62cTXJUX5+IHe/Sx8AZb32H0Qsso+5iwdo44w== Subject: Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path To: Daniel Lezcano , 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 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> <46086489-5a01-16e1-9314-70ae53c01952@gmail.com> <93a26005-aa37-82e1-5c04-a82c9027bac8@linaro.org> From: Quan Xu Message-ID: <5deab1e9-cef2-0511-09d8-cef8e4323f02@gmail.com> Date: Mon, 20 Nov 2017 15:05:01 +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: <93a26005-aa37-82e1-5c04-a82c9027bac8@linaro.org> 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 17:45, Daniel Lezcano wrote: > On 16/11/2017 10:12, Quan Xu wrote: >> >> 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. > I don't know how you tested it, can you elaborate what you meant by > "seems not working so far" ? Daniel, I tried to enable IRQ_TIMINGS* manually. used irq_timings_next_event() to return estimation of the earliest interrupt. However I got a constant. > There are still some work to do to be more efficient. The prediction > based on the irq timings is all right if the interrupts have a simple > periodicity. But as soon as there is a pattern, the current code can't > handle it properly and does bad predictions. > > I'm working on a self-learning pattern detection which is too heavy for > the kernel, and with it we should be able to detect properly the > patterns and re-ajust the period if it changes. I'm in the process of > making it suitable for kernel code (both math and perf). > > One improvement which can be done right now and which can help you is > the interrupts rate on the CPU. It is possible to compute it and that > will give an accurate information for the polling decision. > > As tglx said, talk to each other / work together to make it usable for all use cases. could you share how to enable it to get the interrupts rate on the CPU? I can try it in cloud scenario. of course, I'd like to work with you to improve it. Quan Alibaba Cloud