Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751742AbdIAHcL (ORCPT ); Fri, 1 Sep 2017 03:32:11 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:37841 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751705AbdIAHcI (ORCPT ); Fri, 1 Sep 2017 03:32:08 -0400 X-Google-Smtp-Source: ADKCNb5G48Et40j+qcFMsLBev3srRK1tj88sVbTRj8Zc2FA7bCo18yOPLz9gUKHDMxcraaU4dtrl1Q== Subject: Re: [RFC PATCH v2 7/7] sched/idle: update poll time when wakeup from idle To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, wanpeng.li@hotmail.com, mst@redhat.com, pbonzini@redhat.com, tglx@linutronix.de, rkrcmar@redhat.com, dmatlack@google.com, agraf@suse.de, linux-doc@vger.kernel.org, Quan Xu , Ingo Molnar References: <1504007201-12904-1-git-send-email-yang.zhang.wz@gmail.com> <1504007201-12904-8-git-send-email-yang.zhang.wz@gmail.com> <20170829124655.ann5cipoubl5lppn@hirez.programming.kicks-ass.net> From: Yang Zhang Message-ID: <1d7251cf-e04f-5216-b622-e1864557935e@gmail.com> Date: Fri, 1 Sep 2017 15:30:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170829124655.ann5cipoubl5lppn@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1467 Lines: 33 On 2017/8/29 20:46, Peter Zijlstra wrote: > On Tue, Aug 29, 2017 at 11:46:41AM +0000, Yang Zhang wrote: >> In ttwu_do_wakeup, it will update avg_idle when wakeup from idle. Here >> we just reuse this logic to update the poll time. It may be a little >> late to update the poll in ttwu_do_wakeup, but the test result shows no >> obvious performance gap compare with updating poll in irq handler. >> >> one problem is that idle_stamp only used when using CFS scheduler. But >> it is ok since it is the default policy for scheduler and only consider >> it should enough. >> >> Signed-off-by: Yang Zhang >> Signed-off-by: Quan Xu > > Same broken SoB chain, and not a useful word on why you need to adjust > this crap to begin with. What you want that poll duration to be related > to is the cost of a VMEXIT/VMENTER cycle, not however long we happened > to be idle. Actually, we should compare the cost of VMEXIT/VMENTER with the real duration in idle. We have a rough number of the cost for one VMEXIT/VMENTER(it is about 2k~4k cycles depends on the underlying CPU) and it introduces 4~5 VMENTER/VMEXITs in idle path which may increase about 7us latency in average. So we set the poll duration to 10us by default. Another problem is there is no good way to measure the duration in idle. avg_idle is the only way i find so far. Do you have any suggestion to do it better? Thanks. -- Yang Alibaba Cloud Computing