From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCHv1] xen: increase default number of PIRQs for hardware domains Date: Fri, 5 Dec 2014 10:28:05 +0000 Message-ID: <548188B5.8010400@citrix.com> References: <1417622660-23912-1-git-send-email-david.vrabel@citrix.com> <54818CA5020000780004D0B2@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xwq7P-0000tN-3r for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:28:11 +0000 In-Reply-To: <54818CA5020000780004D0B2@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , David Vrabel Cc: xen-devel@lists.xenproject.org, Tim Deegan , Keir Fraser , Ian Jackson , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 05/12/14 09:44, Jan Beulich wrote: >>>> On 03.12.14 at 17:04, wrote: >> The default limit for the number of PIRQs for hardware domains (dom0) >> is not sufficient for some (x86) systems. >> >> Since the pirq structures are individually and dynamically allocated, >> the limit for hardware domains may be increased to the number of >> possible IRQs. > > I nevertheless disagree to moving the bound up to the Xen internal > limit unconditionally: What use does it have to allow hwdom to use > thousands of MSIs? If a system got that many, the main purpose of > running Xen on it I would expect to be to hand various of the > respective devices to guests. Hence no need for hwdom to have > that many by default, even if this doesn't result in any extra > resource consumption. > > That said, I can see the current default of 256 being too low though. > Quite likely in the absence of a user specified value the default > ought to be derived from nr_irqs - nr_static_irqs rather than being > any fixed number. Considering the default used for nr_irqs, I'd think > along the lines of sqrt(num_present_cpus()) * NR_DYNAMIC_VECTORS > or dom0->max_vcpus * NR_DYNAMIC_VECTORS (or the minimum of > the two) for x86. The reason for a non obvious default like this would need a comment and I can't write one because I can't see a reason for it. Perhaps if you write a suitable comment for your preferred default I can respin this patch? David