From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 43ABE1A2AA5 for ; Tue, 24 Mar 2015 10:29:34 +1100 (AEDT) Received: by wixw10 with SMTP id w10so78282731wix.0 for ; Mon, 23 Mar 2015 16:29:31 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150323230811.GA21966@oracle.com> References: <20150322192726.GB19474@oracle.com> <20150323.122922.887448418154237329.davem@davemloft.net> <20150323165406.GG14061@oracle.com> <20150323.150508.149509757161802782.davem@davemloft.net> <1427149265.4770.238.camel@kernel.crashing.org> <20150323230811.GA21966@oracle.com> Date: Mon, 23 Mar 2015 19:29:31 -0400 Message-ID: Subject: Re: Generic IOMMU pooled allocator From: chase rayfield To: Sowmini Varadhan Content-Type: multipart/alternative; boundary=047d7b5d6592bd7c880511fd095c Cc: aik@au1.ibm.com, aik@ozlabs.ru, anton@au1.ibm.com, paulus@samba.org, sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, David Miller List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --047d7b5d6592bd7c880511fd095c Content-Type: text/plain; charset=UTF-8 On Mar 23, 2015 7:13 PM, "Sowmini Varadhan" wrote: > > On (03/24/15 09:21), Benjamin Herrenschmidt wrote: > > > > So we have two choices here that I can see: > > > > - Keep that old platform use the old/simpler allocator > > Problem with that approach is that the base "struct iommu" structure > for sparc gets a split personality: the older one is used with > the older allocator, and other ugly things ensue. (alternatively, > you end up duplicating a version of the code with the flush_all > inlined). > > > - Try to regain the bulk of that benefit with the new one > > > > Sowmini, I see various options for the second choice. We could stick to > > 1 pool, and basically do as before, ie, if we fail on the first pass of > > alloc, it means we wrap around and do a flush, I don't think that will > > cause a significant degradation from today, do you ? We might have an > > occasional additional flush but I would expect it to be in the noise. > > Isn't this essentially what I have in patch v5 here: > http://www.spinics.net/lists/sparclinux/msg13534.html > > (the ops->reset is the flushall indirection, can be renamed if the > latter is preferred) > > > Dave, what's your feeling there ? Does anybody around still have some > > HW that we can test with ? > > I actually tested this on a V440 and a ultra45 (had a heck of a > time finding these, since the owners keep them turned off because > they are too noisy and consume too much power :-). So we need tests then more than hw?.... I have an ultra1, ultra10 and t2000 I can test on if needed. And I'd appreciate my caches not being flushed excessively on these boxes :-) too. I'll see if I can't get Gentoo on the u10 tonight. Also... It would be more "green" to make the code run faster on these boxes than otherwise! --047d7b5d6592bd7c880511fd095c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 23, 2015 7:13 PM, "Sowmini Varadhan" <sowmini.varadhan@oracle.com> wrote: >
> On (03/24/15 09:21), Benjamin Herrenschmidt wrote:
> >
> > So we have two choices here that I can see:
> >
> >=C2=A0 - Keep that old platform use the old/simpler allocator
>
> Problem with that approach is that the base "struct iommu" s= tructure
> for sparc gets a split personality: the older one is used with
> the older allocator, and other ugly things ensue.=C2=A0 (alternatively= ,
> you end up duplicating a version of the code with the flush_all
> inlined).
>
> >=C2=A0 - Try to regain the bulk of that benefit with the new one > >
> > Sowmini, I see various options for the second choice. We could st= ick to
> > 1 pool, and basically do as before, ie, if we fail on the first p= ass of
> > alloc, it means we wrap around and do a flush, I don't think = that will
> > cause a significant degradation from today, do you ? We might hav= e an
> > occasional additional flush but I would expect it to be in the no= ise.
>
> Isn't this essentially what I have in patch v5 here:
> http= ://www.spinics.net/lists/sparclinux/msg13534.html
>
> (the ops->reset is the flushall indirection, can be renamed if the<= br> > latter is preferred)
>
> > Dave, what's your feeling there ? Does anybody around still h= ave some
> > HW that we can test with ?
>
> I actually tested this on a V440 and a ultra45 (had a heck of a
> time finding these, since the owners keep them turned off because
> they are too noisy and consume too much power :-).

So we need tests then more than hw?.... I have an ultra1, ul= tra10 and t2000 I can test on if needed. And I'd appreciate my caches n= ot being flushed excessively on these boxes :-) too. I'll see if I can&= #39;t get Gentoo on the u10 tonight.

Also... It would be more "green" to make the code = run faster on these boxes than otherwise!

--047d7b5d6592bd7c880511fd095c--