Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751579AbdF0N5G (ORCPT ); Tue, 27 Jun 2017 09:57:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44796 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751466AbdF0N45 (ORCPT ); Tue, 27 Jun 2017 09:56:57 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 204CBC05FFDE Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 204CBC05FFDE Subject: Re: [PATCH 2/2] x86/idle: use dynamic halt poll To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Cc: Wanpeng Li , Yang Zhang , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Jonathan Corbet , tony.luck@intel.com, Borislav Petkov , Peter Zijlstra , mchehab@kernel.org, Andrew Morton , krzk@kernel.org, jpoimboe@redhat.com, Andy Lutomirski , Christian Borntraeger , Thomas Garnier , Robert Gerst , Mathias Krause , douly.fnst@cn.fujitsu.com, Nicolai Stange , Frederic Weisbecker , dvlasenk@redhat.com, Daniel Bristot de Oliveira , yamada.masahiro@socionext.com, mika.westerberg@linux.intel.com, Chen Yu , aaron.lu@intel.com, Steven Rostedt , Kyle Huey , Len Brown , Prarit Bhargava , hidehiro.kawai.ez@hitachi.com, fengtiantian@huawei.com, pmladek@suse.com, jeyu@redhat.com, Larry.Finger@lwfinger.net, zijun_hu@htc.com, luisbg@osg.samsung.com, johannes.berg@intel.com, niklas.soderlund+renesas@ragnatech.se, zlpnobody@gmail.com, Alexey Dobriyan , fgao@48lvckh6395k16k5.yundunddos.com, ebiederm@xmission.com, Subash Abhinov Kasiviswanathan , Arnd Bergmann , Matt Fleming , Mel Gorman , "linux-kernel@vger.kernel.org" , linux-doc@vger.kernel.org, linux-edac@vger.kernel.org, kvm References: <1498130534-26568-1-git-send-email-root@ip-172-31-39-62.us-west-2.compute.internal> <1498130534-26568-3-git-send-email-root@ip-172-31-39-62.us-west-2.compute.internal> <4444ffc8-9e7b-5bd2-20da-af422fe834cc@redhat.com> <2245bef7-b668-9265-f3f8-3b63d71b1033@gmail.com> <7d085956-2573-212f-44f4-86104beba9bb@gmail.com> <05ec7efc-fb9c-ae24-5770-66fc472545a4@redhat.com> <20170627134043.GA1487@potion> From: Paolo Bonzini Message-ID: <2771f905-d1b0-b118-9ae9-db5fb87f877c@redhat.com> Date: Tue, 27 Jun 2017 15:56:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170627134043.GA1487@potion> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 27 Jun 2017 13:56:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1340 Lines: 31 On 27/06/2017 15:40, Radim Krčmář wrote: >> ... which is not necessarily _wrong_. It's just a different heuristic. > Right, it's just harder to use than host's single_task_running() -- the > VCPU calling vcpu_is_preempted() is never preempted, so we have to look > at other VCPUs that are not halted, but still preempted. > > If we see some ratio of preempted VCPUs (> 0?), then we stop polling and > yield to the host. Working under the assumption that there is work for > this PCPU if other VCPUs have stuff to do. The downside is that it > misses information about host's topology, so it would be hard to make it > work well. I would just use vcpu_is_preempted on the current CPU. From guest POV this option is really a "f*** everyone else" setting just like idle=poll, only a little more polite. If we've been preempted and we were polling, there are two cases. If an interrupt was queued while the guest was preempted, the poll will be treated as successful anyway. If it hasn't, let others run---but really that's not because the guest wants to be polite, it's to avoid that the scheduler penalizes it excessively. So until it's preempted, I think it's okay if the guest doesn't care about others. You wouldn't use this option anyway in overcommitted situations. (I'm still not very convinced about the idea). Paolo