On Mar 23, 2015 7:13 PM, "Sowmini Varadhan" <sowmini.varad...@oracle.com> 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!
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
