From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751938AbdKTSBX (ORCPT ); Mon, 20 Nov 2017 13:01:23 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:35148 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751881AbdKTSBU (ORCPT ); Mon, 20 Nov 2017 13:01:20 -0500 X-Google-Smtp-Source: AGs4zMaE05vDBRep65bwt4MdKlxfYA3kmpG1RIzblOpSMvxizqgPBLtn18rZc3QAC+UiQ37oLRTnYQ== Subject: Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path To: Quan Xu , 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> <5deab1e9-cef2-0511-09d8-cef8e4323f02@gmail.com> From: Daniel Lezcano Message-ID: <365f1aaa-0cda-ef58-5574-27810ec1789a@linaro.org> Date: Mon, 20 Nov 2017 19:01:14 +0100 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: <5deab1e9-cef2-0511-09d8-cef8e4323f02@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/11/2017 08:05, Quan Xu wrote: [ ... ] >>>> 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. The irq timings gives you an indication of the next interrupt deadline. This information is a piece of the puzzle, you need to combine it with the next timer expiration, and the next scheduling event. Then take the earliest event in a timeline basis. Using the trivial scheme above will work well with workload like videos or mp3 but will fail as soon as the interrupts are not coming in a regular basis and this is where the pattern recognition algorithm must act. >> 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. Sure, I will be glad if we can collaborate. I have some draft code but before sharing it I would like we define what is the rate and what kind of information we expect to infer from it. From my point of view it is a value indicating the interrupt period per CPU, a short value indicates a high number of interrupts on the CPU. This value must decay with the time, the question here is what decay function we apply to the rate from the last timestamp ? -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog