On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller <del...@gmx.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, and I delayed it to the
merge window.
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, 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. 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?
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 how XPS_MIN_MAP_ALLOC can go negative for a 16-byte case (well,
it's zero on 32-bit architectures).
David: the issue wrt XPS is this:
#define XPS_MIN_MAP_ALLOC ((L1_CACHE_BYTES - sizeof(struct xps_map)) \
/ sizeof(u16))
Comments?
Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
