Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751730AbdIML4g (ORCPT ); Wed, 13 Sep 2017 07:56:36 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:34602 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbdIML4e (ORCPT ); Wed, 13 Sep 2017 07:56:34 -0400 X-Google-Smtp-Source: AOwi7QBuR50ExmIJsaXOdV7FaDingrUMNzlMWaWm09wki7bP+WY/OsdUbhNx0/nCywzMApdnvWo2Ug== Subject: Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support To: "Michael S. Tsirkin" Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, wanpeng.li@hotmail.com, pbonzini@redhat.com, tglx@linutronix.de, rkrcmar@redhat.com, dmatlack@google.com, agraf@suse.de, peterz@infradead.org, linux-doc@vger.kernel.org, Quan Xu References: <1504007201-12904-1-git-send-email-yang.zhang.wz@gmail.com> <20170829174147-mutt-send-email-mst@kernel.org> From: Yang Zhang Message-ID: <259c95bc-3641-965b-4054-a233a6ee785c@gmail.com> Date: Wed, 13 Sep 2017 19:56:23 +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: <20170829174147-mutt-send-email-mst@kernel.org> 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: 1146 Lines: 33 On 2017/8/29 22:56, Michael S. Tsirkin wrote: > On Tue, Aug 29, 2017 at 11:46:34AM +0000, Yang Zhang wrote: >> Some latency-intensive workload will see obviously performance >> drop when running inside VM. > > But are we trading a lot of CPU for a bit of lower latency? > >> The main reason is that the overhead >> is amplified when running inside VM. The most cost i have seen is >> inside idle path. >> >> This patch introduces a new mechanism to poll for a while before >> entering idle state. If schedule is needed during poll, then we >> don't need to goes through the heavy overhead path. > > Isn't it the job of an idle driver to find the best way to > halt the CPU? > > It looks like just by adding a cstate we can make it > halt at higher latencies only. And at lower latencies, > if it's doing a good job we can hopefully use mwait to > stop the CPU. > > In fact I have been experimenting with exactly that. > Some initial results are encouraging but I could use help > with testing and especially tuning. If you can help > pls let me know! Quan, Can you help to test it and give result? Thanks. -- Yang Alibaba Cloud Computing