From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dItBK-00044o-1C for qemu-devel@nongnu.org; Thu, 08 Jun 2017 04:52:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dItBG-0006Vm-QA for qemu-devel@nongnu.org; Thu, 08 Jun 2017 04:52:42 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:55661 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dItBG-0006Vb-JN for qemu-devel@nongnu.org; Thu, 08 Jun 2017 04:52:38 -0400 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v588oCIU111065 for ; Thu, 8 Jun 2017 04:52:37 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0b-001b2d01.pphosted.com with ESMTP id 2axv361vd4-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 08 Jun 2017 04:52:37 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 8 Jun 2017 09:52:35 +0100 References: <20170529135520.101429-1-pasic@linux.vnet.ibm.com> <20170529135520.101429-5-pasic@linux.vnet.ibm.com> <87a85sc102.fsf@secure.mitica> <4f30017b-22a9-496a-82d2-637a3317c692@linux.vnet.ibm.com> <20170601133251.4869b001.cornelia.huck@de.ibm.com> <8f9e006d-50f1-ac03-568e-5467f86e53e5@linux.vnet.ibm.com> <87y3t3brp5.fsf@secure.mitica> From: Halil Pasic Date: Thu, 8 Jun 2017 10:52:33 +0200 MIME-Version: 1.0 In-Reply-To: <87y3t3brp5.fsf@secure.mitica> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Message-Id: <57adc010-13db-fa6e-a50a-0e54f184c84f@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v2 4/7] s390x/css: add missing css state conditionally List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: Cornelia Huck , Dong Jia Shi , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" On 06/07/2017 08:03 PM, Juan Quintela wrote: > Halil Pasic wrote: >> On 06/01/2017 01:32 PM, Cornelia Huck wrote: >>> On Thu, 1 Jun 2017 11:35:27 +0200 >>> Halil Pasic wrote: >>> > >>>>> >>>>> I was about to suggest to move css from pointer to an embedded struct, >>>>> and then noticed that MAX_CSSID is .... 65535. I guess that this is >> >> #define MAX_CSSID 255 >> ("include/hw/s390x/css.h" line 23) > > I have to grep better O:-) > >>>>> going to be sparse, very sparse. Perhaps there is an easier way to >>>>> transmit it? >>>>> >>>>> You are transmiting: >>>>> >>>>> 65000 structs each of size MAX_CHPID (255) and each element is byte + >>>>> byte +byte = 65000 * 255 * 3 = 47 MB. >>>>> >>>>> If it is really sparse, I think that sending something like a list >>>>> of could make sense, no? >>>>> >>>>> Or I am missunderstanding something? >>>>> >>>> >>>> I think you are misunderstanding. Sparse arrays of pointers were not >>>> supported in the first place. Support was added by me recentily (patch >>>> 07d4e69 "migration/vmstate: fix array of ptr with nullptrs"). For a null >>>> pointer just a single byte is transmitted. So we should be more like >>>> around 64KB, given that it is really sparse. Bottom line, the in stream >> >> Given that my calculation is also wrong. The overhead is below 255 bytes >> (overhead compared to not transferring anything for null pointers, which >> is clearly an unrealistic lower bound case). > > Yeap, I greeped wrong. 255 x 255 makes no sense to optimize at all. > Sorry for the noise. > >>>> representation is at least as efficient as the in memory representation. >>>> >>>> Of course we could do something special for sparse arrays of pointers in >>>> general, and indeed, one of the possibilities is a list/vector of non >>>> null indexes. >>> >>> Just as discussion fodder: For a run-of-the-mill qemu guest, I'd expect >>> a low double-digit number of subchannels in css 0xfe, in subchannel set >>> 0, which are clustered right at the beginning, and one chpid (0) in css >>> 0xfe. >>> >>> As the subchannel id is autogenerated based upon the devno (if >>> provided), it is easy to have subchannels in an arbitrary subchannel >>> set (of which there are only four), but to get high subchannel ids with >>> a lot of empty slots before, you'd have to create a lot (really a lot) >>> of devices and then detach most of them again - not a very likely >>> pattern. >>> >>> The 3270 support does not really change much: one additional subchannel >>> (with the same characteristics) and one further chpid. But I don't >>> expect many people to use 3270, and it is not (yet) migratable anyway. >>> >>> vfio-ccw devices will be in another css (possibly mapped), but they are >>> not migrateable either. >>> >>> So if we want to optimize, some "nothing of interest beyond that point" >>> marker might be useful - but not very. >> >> Thus I do not think we need extra sparse array handling for this. >> >> (Nevertheless an extra sparse array handling might make sense for >> vmstate core, provided there is an use case). > > So, I retire all my objections. > > Again, sorry for the noise. No problem. Actually, it's appreciated! Better have some false positives than having something stupid slipping in and having to live with it. Thanks for your review! Regards, Halil