Hi Greg,

> -----Original Message-----
> From: gre...@linuxfoundation.org <gre...@linuxfoundation.org>
> Sent: Thursday, February 7, 2019 6:52 PM
> To: Alexey Brodkin <alexey.brod...@synopsys.com>
> Cc: david.lai...@aculab.com; ge...@linux-m68k.org; pet...@infradead.org; 
> sta...@vger.kernel.org;
> t...@linutronix.de; will.dea...@arm.com; Vineet Gupta 
> <vineet.gup...@synopsys.com>; linux-snps-
> a...@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-=wj3q7ckmqywfzssqutqkehnwvgrrbcwe7avj70s8i5...@mail.gmail.com/

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Reply via email to