Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752031AbdH2Mm4 convert rfc822-to-8bit (ORCPT ); Tue, 29 Aug 2017 08:42:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7973 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751485AbdH2Mmy (ORCPT ); Tue, 29 Aug 2017 08:42:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 50CBA356DB Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=cohuck@redhat.com Date: Tue, 29 Aug 2017 14:42:47 +0200 From: Cornelia Huck To: David Hildenbrand Cc: Radim =?UTF-8?B?S3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-mips@linux-mips.org, kvm-ppc@vger.kernel.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Paolo Bonzini , Christoffer Dall , Marc Zyngier , Christian Borntraeger , James Hogan , Paul Mackerras , Alexander Graf Subject: Re: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus Message-ID: <20170829144247.5b0644dc.cohuck@redhat.com> In-Reply-To: References: <20170821203530.9266-1-rkrcmar@redhat.com> <20170821203530.9266-2-rkrcmar@redhat.com> <67a8b09c-3e7a-943d-8684-f9ad6e70514b@redhat.com> <20170829132342.1ef25500.cohuck@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 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.30]); Tue, 29 Aug 2017 12:42:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1457 Lines: 38 On Tue, 29 Aug 2017 14:05:40 +0200 David Hildenbrand wrote: > On 29.08.2017 13:23, Cornelia Huck wrote: > > On Tue, 22 Aug 2017 13:31:27 +0200 > > David Hildenbrand wrote: > > > >> On 21.08.2017 22:35, Radim Krčmář wrote: > >>> We can add a variable instead of scanning all online VCPUs to know how > >>> many are started. We can't trivially tell which VCPU is the last one, > >>> though. > >> > >> You could keep the started vcpus in a list. Then you might drop unsigned > >> started_vcpus; > >> > >> No started vcpus: Start pointer NULL > >> Single started vcpu: Only one element in the list (easy to check) > >>> 1 started vcpus: More than one element int he list (easy to check) > > > > I'm not sure the added complication of keeping a list buys us much > > here: We only have the "look for the last vcpu not stopped" operation > > for the 2->1 transition. > > > > That is wrong, we also have to know the last remaining (started) VCPU. > For that, right now we have to iterate over all VCPUs. Yes, but that's only for the 2->1 transition... and all in all that is still much better that before. > > There shouldn't be much complexity. We already perform changes under a > lock, so it is as simple as adding/removing from the list. > > Detecting the transitions boils down to looking at two pointers. Having a private vcpu list feels a bit wrong... and I don't really see much benefit.