svn commit: r244732 - head/sys/sys

Attilio Rao attilio at freebsd.org
Fri Dec 28 12:53:38 UTC 2012


On Fri, Dec 28, 2012 at 9:20 AM, Gleb Smirnoff <glebius at freebsd.org> wrote:
> On Thu, Dec 27, 2012 at 08:37:24AM -0800, Attilio Rao wrote:
> A> > Speaking of which, as you are here, I just found out that r241037
> A> > breaks the alignment of the structure.
> A> > Infact the padding member is not updated accordingly.
> A> >
> A> > We don't have a param to control L2 caches, but I think that we can
> A> > safely align them to the L1 cacheline for sure.
> A> > Also, note that this padding is completely broken for MI requirements
> A> > (it just assumes blindly 128 bytes L2 cachelines, which not always
> A> > true even on i386).
> A>
> A> More specifically this patch:
> A> http://www.freebsd.org/~attilio/bufring_pad.patch
> A>
> A> Of course I don't think the optimization is important in the
> A> DEBUG_BUFRING on case, so the patch should be fine.
>
> Agreed, thanks. And thanks for removing the br_prod_bufs.
>
> Sorry for breaking alignment in r241037.
>
> And last time we talked about alignment, it was noticed that our
> current CACHE_LINE_SIZE on amd64 is 128, while real size is 64.
> This 128 was some optimisation proposed by Intel for some past
> generation of CPUs and is no longer actual. Shouldn't we change it
> back to 64?

There was a recent thread on -arch about it. By Intel devs tests it
seems that CACHE_LINE_SIZE=128 really gives a performance boost when
NLM prefetcher is enabled while it doesn't hurt otherwise.

Did you also rewview the second patch I sent?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein


More information about the svn-src-head mailing list