From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [RFC]Two ideas to optimize updating irq routing table Date: Wed, 26 Mar 2014 09:16:27 +0100 Message-ID: <53328CDB.4050702@de.ibm.com> References: <33183CC9F5247A488A2544077AF19020815DA9BD@SZXEMA503-MBS.china.huawei.com> <53317892.2050506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "gleb@redhat.com" , "mst@redhat.com" , "avi.kivity@gmail.com" , "Herongguang (Stephen)" , "Huangweidong (C)" To: Paolo Bonzini , "Gonglei (Arei)" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" Return-path: Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:34637 "EHLO e06smtp11.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbaCZIQd (ORCPT ); Wed, 26 Mar 2014 04:16:33 -0400 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 26 Mar 2014 08:16:31 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id B757A219005C for ; Wed, 26 Mar 2014 08:16:23 +0000 (GMT) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s2Q8GHoJ66322618 for ; Wed, 26 Mar 2014 08:16:17 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s2Q8GS43028027 for ; Wed, 26 Mar 2014 02:16:28 -0600 In-Reply-To: <53317892.2050506@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 25/03/14 13:37, Paolo Bonzini wrote: > Il 25/03/2014 04:19, Gonglei (Arei) ha scritto: >> Based on discussions in: >> http://lists.gnu.org/archive/html/qemu-devel/2013-11/threads.html#03322 >> >> About KVM_SET_GSI_ROUTING ioctl, I tested changing RCU to SRCU, but unfortunately >> it looks like SRCU's grace period is no better than RCU. > > Really? This is not what Christian Borntraeger claimed at http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/118083 -- in fact, Andrew Theurer is currently testing a variant of that patch and I was going to post it for 3.16. > > Have you tried synchronize_srcu_expedited? Unlike the RCU variant, you can use this function. On my system I have HZ=100 and lots of CPUs. So RCUs "every cpu has scheduled" is certainly slower than SRCUs algorithm (/* * We use an adaptive strategy for synchronize_srcu() and especially for * synchronize_srcu_expedited(). We spin for a fixed time period * (defined below) to allow SRCU readers to exit their read-side critical * sections. If there are still some readers after 10 microseconds, * we repeatedly block for 1-millisecond time periods. This approach * has done well in testing, so there is no need for a config parameter. */ ) With HZ==1000 and a NO. CPUs small SRCUs spinning might be in the same delay range than classic RCU depending on how long the read side critical section is (if we move from spinning to blocking) So using synchronize_srcu_expedited is certainly something to test as it increased the spinning time. Christian