From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752131AbbIBGBm (ORCPT ); Wed, 2 Sep 2015 02:01:42 -0400 Received: from blu004-omc1s16.hotmail.com ([65.55.116.27]:50919 "EHLO BLU004-OMC1S16.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751290AbbIBGBk (ORCPT ); Wed, 2 Sep 2015 02:01:40 -0400 X-TMN: [waI3wkOQu4Edg4IlfNSji/7q78MYJUJX] X-Originating-Email: [wanpeng.li@hotmail.com] Message-ID: Subject: Re: [PATCH v4 0/3] KVM: Dynamic Halt-Polling To: David Matlack References: CC: Paolo Bonzini , kvm list , "linux-kernel@vger.kernel.org" , Peter Kieser From: Wanpeng Li Date: Wed, 2 Sep 2015 14:01:31 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Sep 2015 06:01:38.0626 (UTC) FILETIME=[D4E81220:01D0E544] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/2/15 9:49 AM, David Matlack wrote: > On Tue, Sep 1, 2015 at 5:29 PM, Wanpeng Li wrote: >> On 9/2/15 7:24 AM, David Matlack wrote: >>> On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li wrote: > >>>> Why this can happen? >>> Ah, probably because I'm missing 9c8fd1ba220 (KVM: x86: optimize delivery >>> of TSC deadline timer interrupt). I don't think the edge case exists in >>> the latest kernel. >> >> Yeah, hope we both(include Peter Kieser) can test against latest kvm tree to >> avoid confusing. The reason to introduce the adaptive halt-polling toggle is >> to handle the "edge case" as you mentioned above. So I think we can make >> more efforts improve v4 instead. I will improve v4 to handle short halt >> today. ;-) > That's fine. It's just easier to convey my ideas with a patch. FYI the > other reason for the toggle patch was to add the timer for kvm_vcpu_block, > which I think is the only way to get dynamic halt-polling right. Feel free > to work on top of v4! I introduce your idea to shrink/grow poll time in v5 by detecting long/short halt and the performance looks good. Many thanks your help, David! ;-) Regards, Wanpeng Li > > >>>> Did you test your patch against a windows guest? >>> I have not. I tested against a 250HZ linux guest to check how it performs >>> against a ticking guest. Presumably, windows should be the same, but at a >>> higher tick rate. Do you have a test for Windows? >> >> I just test the idle vCPUs usage. >> >> >> V4 for windows 10: >> >> +-----------------+----------------+-----------------------+ >> | | | >> | >> | w/o halt-poll | w/ halt-poll | dynamic(v4) halt-poll >> | >> +-----------------+----------------+-----------------------+ >> | | | >> | >> | ~2.1% | ~3.0% | ~2.4% >> | >> +-----------------+----------------+-----------------------+ > I'm not seeing the same results with v4. With a 250HZ ticking guest > I see 15% c0 with halt_poll_ns=2000000 and 1.27% with halt_poll_ns=0. > Are you running one vcpu per pcpu? > > (The reason for the overhead: the new tracepoint shows each vcpu is > alternating between 0 and 500 us.) > >> V4 for linux guest: >> >> +-----------------+----------------+-------------------+ >> | | | | >> | w/o halt-poll | w/ halt-poll | dynamic halt-poll | >> +-----------------+----------------+-------------------+ >> | | | | >> | ~0.9% | ~1.8% | ~1.2% | >> +-----------------+----------------+-------------------+ >> >> >> Regards, >> Wanpeng Li