DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 204CBC05FFDE
Subject: Re: [PATCH 2/2] x86/idle: use dynamic halt poll
To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
Cc: Wanpeng Li <kernellwp@gmail.com>, Yang Zhang <yang.zhang.wz@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        the arch/x86 maintainers <x86@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>, tony.luck@intel.com,
        Borislav Petkov <bp@alien8.de>, Peter Zijlstra <peterz@infradead.org>,
        mchehab@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
        krzk@kernel.org, jpoimboe@redhat.com,
        Andy Lutomirski <luto@kernel.org>,
        Christian Borntraeger <borntraeger@de.ibm.com>,
        Thomas Garnier <thgarnie@google.com>, Robert Gerst <rgerst@gmail.com>,
        Mathias Krause <minipli@googlemail.com>, douly.fnst@cn.fujitsu.com,
        Nicolai Stange <nicstange@gmail.com>,
        Frederic Weisbecker <fweisbec@gmail.com>, dvlasenk@redhat.com,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        yamada.masahiro@socionext.com, mika.westerberg@linux.intel.com,
        Chen Yu <yu.c.chen@intel.com>, aaron.lu@intel.com,
        Steven Rostedt <rostedt@goodmis.org>, Kyle Huey <me@kylehuey.com>,
        Len Brown <len.brown@intel.com>, Prarit Bhargava <prarit@redhat.com>,
        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 <adobriyan@gmail.com>,
        fgao@48lvckh6395k16k5.yundunddos.com, ebiederm@xmission.com,
        Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>,
        Arnd Bergmann <arnd@arndb.de>, Matt Fleming <matt@codeblueprint.co.uk>,
        Mel Gorman <mgorman@techsingularity.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        linux-doc@vger.kernel.org, linux-edac@vger.kernel.org,
        kvm <kvm@vger.kernel.org>
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>
 <fd7acd49-9d37-4495-79cd-250e3b54cac2@redhat.com>
 <CANRm+Cyd4ycNdDN8=M66re5RhnrJF=3HPiPuJeMAUgLRb1qBcg@mail.gmail.com>
 <05ec7efc-fb9c-ae24-5770-66fc472545a4@redhat.com>
 <20170627134043.GA1487@potion>
From: Paolo Bonzini <pbonzini@redhat.com>
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
Sender: linux-kernel-owner@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