From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH 2/4] iommu: add a bitmap based dma address allocator Date: Wed, 25 Nov 2015 09:43:49 -0700 Message-ID: <5655E545.1010509@fb.com> References: <4c0804c85404be81acfe81fcd402f1af484e9d5f.1448401089.git.shli@fb.com> <1448402209.44976.109.camel@intel.com> <20151124220511.GA2106568@devbig084.prn1.facebook.com> <20151125144613.GA3763@suse.de> <1448469599.44976.134.camel@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1448469599.44976.134.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Woodhouse, David" , "jroedel-l3A5Bk7waGM@public.gmane.org" , Shaohua Li Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "Kernel-team-b10kYP2dOMg@public.gmane.org" List-Id: iommu@lists.linux-foundation.org On 11/25/2015 09:40 AM, Woodhouse, David wrote: > On Wed, 2015-11-25 at 15:46 +0100, jroedel-l3A5Bk7waGM@public.gmane.org wrote: >> On Tue, Nov 24, 2015 at 02:05:12PM -0800, Shaohua Li wrote: >>> The lib/iommu-common.c uses a bitmap and a lock. This implementation >>> actually uses a percpu_ida which completely avoids locking. It would be >>> possible to make lib/iommu-common.c use percpu_ida too if somebody wants >>> to do it, but I think this shouldn't be a blocker for these patches >>> giving it has huge performance gain. >> >> It doesn't "completely avoids locking", the percpu_ida code uses a lock >> internally too. Also, what is the memory and device address space >> overhead per cpu? > > A percpu lock doesn't bounce cachelines between CPUs very much, so from > that point of view it might as well not exist :) As long as the address space can remain more than ~50% empty, it is indeed practically lockless. Are we ever worried about higher utilization? If so, in my experience percpu_ida fails miserable near or at exhaustion. -- Jens Axboe