Hi Greg, > -----Original Message----- > From: gregkh@xxxxxxxxxxxxxxxxxxx <gregkh@xxxxxxxxxxxxxxxxxxx> > Sent: Thursday, February 7, 2019 6:52 PM > To: Alexey Brodkin <alexey.brodkin@xxxxxxxxxxxx> > Cc: David.Laight@xxxxxxxxxx; geert@xxxxxxxxxxxxxx; peterz@xxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; > tglx@xxxxxxxxxxxxx; will.deacon@xxxxxxx; Vineet Gupta <vineet.gupta1@xxxxxxxxxxxx>; linux-snps- > arc@xxxxxxxxxxxxxxxxxxx > 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-=wj3Q7CkMQYwfZSsqUTqkEhNwVGrRbCwe7AVJ70S8i5sWw@xxxxxxxxxxxxxx/ 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 _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
