Hi Greg,
-----Original Message----- From: gregkh@linuxfoundation.org gregkh@linuxfoundation.org Sent: Thursday, February 7, 2019 6:52 PM To: Alexey Brodkin alexey.brodkin@synopsys.com Cc: David.Laight@ACULAB.COM; geert@linux-m68k.org; peterz@infradead.org; stable@vger.kernel.org; tglx@linutronix.de; will.deacon@arm.com; Vineet Gupta vineet.gupta1@synopsys.com; linux-snps- arc@lists.infradead.org Subject: Re: patch "devres: Align data[] to ARCH_KMALLOC_MINALIGN" added to driver-core-linus
[snip]
Ah, I was waiting to see if you would notice :)
Well I was just patiently waiting as I guess there's a long queue of patches to deal with in your inbox :)
See this question from Linus about this patch: https://lore.kernel.org/lkml/CAHk-=wj3Q7CkMQYwfZSsqUTqkEhNwVGrRbCwe7AVJ70S8i...
I didn't see that. Though I intentionally sent my patch to most if not all arch maintainers so they might share their concerns... but IIRC nobody ever replied with either concerns or acks.
Also I do agree that it's a trade-off between: 1. Predictability I was completely sure devm-allocated buffer is the same as anything kmalloced except some meta-data stored _separately_ and so supposed alignment should match as well... but how wrong that feeling was.
2. Optimization Indeed it's so sweet when both devm "meta-data" and real small buffer fit into 1 cache line.
I figured that you all did this for a good reason, and wasting that much space was going to be ok. But, I wanted to be sure, so if you never noticed it, I figured it was not that pressing of an issue.
It's not super pressing because: 1. Fortunately [or unfortunately] this problem happens only in pretty rare cases like that Etnaviv driver where I first caught it.
2. There's a solution and affected parties may apply known patch locally.
Anyway, is this really needed to be backported?
For us poor ARC developers and users it's really needed as our tools ABI sets 32-bit alignment for 64-bit types. See that's the same optimization - why wasting precious bytes on useless holes - let's pack data tighter :)
So having that fix at least in the most recent LTS (i.e. 4.19) would be really good. As for older kernels I think for now we may not touch them as indeed change is quite intrusive.
-Alexey