Message-ID: <56393D46.6060903@gmx.de>
Date:	Wed, 4 Nov 2015 00:03:34 +0100
From:	Helge Deller <deller@....de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Miller <davem@...emloft.net>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Parisc List <linux-parisc@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	John David Anglin <dave.anglin@...l.net>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [GIT PULL] parisc architecture updates for v4.3

Hi Linus,

On 03.11.2015 22:01, Linus Torvalds wrote:
> On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller <deller@....de> wrote:
>>
>> please pull some patches for the parisc architecture for kernel v4.3 from:
> 
> So no way was I going to pull that for 4.3,

Yes, since you didn't pulled I assumed you saw some kind of problem with the patches.
Maybe it's even my fault, because I should have explained some more in the pull request,
e.g. that all patches were discussed with the various stakeholders, and e.g. that
I was late in sending this pull request, because I was waiting for some benchmark results.

> and I delayed it to the merge window.

Ok.
 
> However, even now that we're in the merge window, and I look at it again:
> 
>> The most important change is that we reduce L1_CACHE_BYTES to 16 bytes, for
>> which a trivial patch for XPS in the network layer was needed.
> 
> I'd really want the network people involved with that change, 

As David already answered, it was discussed with them:
http://marc.info/?t=144554413000001&r=1&w=2

> and I'm
> also wondering why you seem to want to re-define L1_CACHE_BYTES to
> something that it isn't.
> I doubt the PA-RISC L1 cacheline really is 16 bytes. 

Sadly it's nowhere clearly documented how big the L1 cacheline of parisc really is.

We are currently experimenting a lot with improving spinlocks on hppa,
that's why we play around with the L1 cache size setting.

In one of the mail threads (where I actually wanted to align the hashes
which we need to protect/simulate the atomic locks) James Bottomleys
gave a pretty good explanation of why it might be beneficial to 
modify L1_CACHE_BYTES for parisc:
 http://permalink.gmane.org/gmane.linux.ports.parisc/26040
The whole mail thread is here:
 http://thread.gmane.org/gmane.linux.ports.parisc/26000

> So this seems to
> be more of a hack around the fact that some data structures may be
> over-aligned, and using that L1_CACHE_BYTES for aligning things that
> really don't want to be that aligned. Maybe it casues less sharing,
> but if it does so at the cost of excessive memory use, it's still
> wrong.
> 
> But that in turn says to me "We should fix the *real* problem, rather
> than hack around it by having PA-RISC lie about its L1 cache size".
> 
> Is there any particular over-alignment that you have determined to be
> the real problem?

I was not very much concerned about any over-alignment, but about the
performance. Reducing L1_CACHE_BYTES gave a performance improvement
on parisc, most likely since we protect atomic accesses through our
atomic spinlocks anyway. 
 
> Also, just looking at other things, we currently do have openrisc that has
> 
>   #define L1_CACHE_BYTES 16
> 
> so presumably openrisc would have had an issue with that XPS thing,

and mn10300.

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists