On Wed, Jan 11, 2017 at 06:03:15PM +0000, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > > transfer data between memory and PCIe adapter. Because of performance
> > > reasons it is important that the CPU cache is not flushed when such
> > > drivers transfer data. Make this possible by allowing these drivers to
> > > override the dma_map_ops pointer. Additionally, introduce the function
> > > set_dma_ops() that will be used by a later patch in this series.
> > >
> > > Signed-off-by: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
> > > Cc: [ ... ]
> >
> > That's a crazy cc: list, you should break this up into smaller pieces,
> > otherwise it's going to bounce...
>
> That's a subset of what scripts/get_maintainer.pl came up with. Suggestions
> for a more appropriate cc-list for a patch like this that touches all
> architectures would be welcome.
You need to break this patch up into a series that can be applied in
sequence, don't change everything all at once. That's a mess to merge,
as you are finding out.
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index 491b4c0ca633..c7cb225d36b0 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -885,6 +885,8 @@ struct dev_links_info {
> > > * a higher-level representation of the device.
> > > */
> > > struct device {
> > > + const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
> > > +
> > > struct device *parent;
> > >
> > > struct device_private *p;
> >
> > Why not put this new pointer down with the other dma fields in this
> > structure? Any specific reason it needs to be first?
>
> Are there CPU architectures for which access to the first member of a
> structure can be encoded and/or executed more efficiently than access to
> other members of a structure? If not, I'm fine with moving the new pointer
> further down.
Why do you think that your pointer is the one that gets to be "most
efficient"? :)
Seriously, no, it doesn't matter at all, it's all just pointer math
which is very fast. Put it with the other stuff please, don't try to
optimize something without ever measuring it.
thanks,
greg k-h
