Re: [PATCH 2/9] Move dma_ops from archdata into struct device

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:

quoted

On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:

quoted

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 <redacted>
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.

quoted

quoted

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