From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754410AbdDKJPw (ORCPT ); Tue, 11 Apr 2017 05:15:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39524 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754508AbdDKJOs (ORCPT ); Tue, 11 Apr 2017 05:14:48 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AA174C059731 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 AA174C059731 Subject: Re: [PATCH 6/6] KVM: perform a wake_up in kvm_make_all_cpus_request To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <20170406202056.18379-1-rkrcmar@redhat.com> <20170406202056.18379-7-rkrcmar@redhat.com> Cc: Christoffer Dall , Andrew Jones , Marc Zyngier , Christian Borntraeger , Cornelia Huck , James Hogan , Paul Mackerras From: Paolo Bonzini Message-ID: <8bdc2f6a-72dd-c5a9-8706-a88cf9d1d9df@redhat.com> Date: Tue, 11 Apr 2017 13:37:54 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170406202056.18379-7-rkrcmar@redhat.com> Content-Type: text/plain; charset=utf-8 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, 11 Apr 2017 09:14:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/04/2017 04:20, Radim Krčmář wrote: > I think that most requests do not need the wake up, so we would flip the > bit then. True. I may need a bit more convincing, but let's see the patches: - point against: on the other hand no wakeup is a bug, possibly hard to find, while an extra wakeup is just annoying. - point in favor: the same argument (multiplied by 9000) would apply to a wait flag in the request number, but it would be obviously stupid to add a no_wait flag to all requests except the couple that need it. Thanks, Paolo