Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752803AbdF0OXw (ORCPT ); Tue, 27 Jun 2017 10:23:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45172 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752310AbdF0OXQ (ORCPT ); Tue, 27 Jun 2017 10:23:16 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A537CC04574E 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=rkrcmar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A537CC04574E Date: Tue, 27 Jun 2017 16:22:51 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini 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 Subject: Re: [PATCH 2/2] x86/idle: use dynamic halt poll Message-ID: <20170627142251.GB1487@potion> 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> <2771f905-d1b0-b118-9ae9-db5fb87f877c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2771f905-d1b0-b118-9ae9-db5fb87f877c@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 27 Jun 2017 14:23:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2166 Lines: 46 2017-06-27 15:56+0200, Paolo Bonzini: > 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. vcpu_is_preempted() on current cpu cannot return true, AFAIK. > 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. I think the poll should be treated as invalid if the window has expired while the VCPU was preempted -- the guest can't tell whether the interrupt arrived still within the poll window (unless we added paravirt for that), so it shouldn't be wasting time waiting for it. > 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. This sounds like a VM entry just to do an immediate VM exit, so paravirt seems better here as well ... (the guest telling the host about its window -- which could also be used to rule it out as a target in the pause loop random kick.) > 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). Me neither. (The same mechanism is applicable to bare-metal, but was never used there, so I would rather bring the guest behavior closer to bare-metal.)