From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752697AbbHGLL6 (ORCPT ); Fri, 7 Aug 2015 07:11:58 -0400 Received: from 8bytes.org ([81.169.241.247]:58178 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbbHGLL5 (ORCPT ); Fri, 7 Aug 2015 07:11:57 -0400 Date: Fri, 7 Aug 2015 13:11:56 +0200 From: Joerg Roedel To: Alex Williamson Cc: iommu@lists.linux-foundation.org, David Woodhouse , linux-kernel@vger.kernel.org, jroedel@suse.de Subject: Re: [PATCH 03/26] iommu/vt-d: Split up iommu->domains array Message-ID: <20150807111156.GY14980@8bytes.org> References: <1438787937-7340-1-git-send-email-joro@8bytes.org> <1438787937-7340-4-git-send-email-joro@8bytes.org> <1438888809.4023.121.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1438888809.4023.121.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 06, 2015 at 01:20:09PM -0600, Alex Williamson wrote: > On Wed, 2015-08-05 at 17:18 +0200, Joerg Roedel wrote: > > static void set_iommu_domain(struct intel_iommu *iommu, u16 did, > > struct dmar_domain *domain) > > { > > - iommu->domains[did] = domain; > > + struct dmar_domain **domains; > > + int idx = did >> 8; > > + > > + if (!iommu->domains[idx]) { > > + size_t size = 256 * sizeof(struct dmar_domain *); > > + iommu->domains[idx] = kzalloc(size, GFP_ATOMIC); > > + } > > + > > + domains = iommu->domains[idx]; > > + if (WARN_ON(!domains)) > > + return; > > + else > > + domains[did & 0xff] = domain; > > } > > I'm tempted to suggest using pages here since we're dealing with 2k > second level arrays, but maybe caring about pointers per page just makes > that ugly. The benefit would be that we avoid the slab-overhead while allocating. But since the VT-d driver is needed on platforms with different page-sizes, the handling would be indeed more complicated because we have to split the index at a different point then depending on the architecture. Joerg