Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751996AbdI2K3z (ORCPT ); Fri, 29 Sep 2017 06:29:55 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:35490 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750927AbdI2K3w (ORCPT ); Fri, 29 Sep 2017 06:29:52 -0400 X-Google-Smtp-Source: AOwi7QBdr2Ws8NX/bv2kWMbEboNGMMZvEHqxmD7lzl6L+17iaOii10YHB1xZH9SEo5u+tAcSudXmUQ== Cc: quan.xu0@gmail.com, 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, Ingo Molnar Subject: Re: [RFC PATCH v2 7/7] sched/idle: update poll time when wakeup from idle To: Peter Zijlstra , Yang Zhang 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: Quan Xu Message-ID: Date: Fri, 29 Sep 2017 18:29:21 +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=gbk; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1438 Lines: 40 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. > > So no. Peter, I think you are right.. IIUC, the time we happened to be idle may contain a chain of VMEXIT/VMENTER cycles, which would be mainly (except the last VMEXIT/VMENTER cycles) for just idle loops. right? as you mentioned, poll duration to be related to is the cost of __a__ VMEXIT/VMENTER cycle. howerver it is very difficult to measure a VMEXIT/VMENTER cycle accurately from kvm guest, we could find out an approximate one -- dropping the idle loops from the time we happened to be idle.. make sense? Quan