> On Apr 2, 2014, at 7:37 AM, Richard Henderson <r...@redhat.com> wrote: > >> On 04/01/2014 03:41 PM, Andrew Pinski wrote: >>> On Tue, Apr 1, 2014 at 3:24 PM, Richard Henderson <r...@redhat.com> wrote: >>> Comments? If approved, should this go in for 4.9, or wait for stage1? >>> Certainly it's self-contained... >> >> On Cavium's thunder processor the cache line size is going to be >> bigger than 64 bytes, what is your solution to improve performance on >> target's like Thunder? > > We can expand the number reasonably. The only thing it controls is layout of > some of the internal data structures to attempt to put different locks on > different lines. > > Is 128 big enough for Thunder? Honestly, I may well not even have it right > for > the processor we have in house. I didn't bother trying to track down docs to > find out.
Yes 128 should be enough. Thanks, Andrew > >> Also I think the default page size for most Linux distros is going to >> be 64k on aarch64 including Redhat Linux so it makes sense not to >> define FIXED_PAGE_SIZE. > > Heh. It turns out these page size defines aren't used any more at all. > During > one of the rewrites we must have delete the bits that used it. I'll get rid > of > all of them so as to be less confusing. > >> I will implement the ILP32 version of this patch once it goes in, >> there needs a few changes in gtm_jmpbuf due to long and pointers being >> 32bit but the assembly storing 64bits always. > > I can minimize those changes now by using unsigned long long... > > > r~ >
