Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752650AbbDCQtA (ORCPT ); Fri, 3 Apr 2015 12:49:00 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:48895 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751491AbbDCQs6 (ORCPT ); Fri, 3 Apr 2015 12:48:58 -0400 Date: Fri, 03 Apr 2015 12:48:55 -0400 (EDT) Message-Id: <20150403.124855.96516097693494126.davem@davemloft.net> To: bhelgaas@google.com Cc: bjorn@helgaas.com, bjorn.helgaas@gmail.com, sparclinux@vger.kernel.org, linux-pci@vger.kernel.org, yinghai@kernel.org, david.ahern@oracle.com, linux-kernel@vger.kernel.org Subject: Re: d63e2e1f3df breaks sparc/T5-8 From: David Miller In-Reply-To: <20150403154526.GB10892@google.com> References: <20150329.113250.2136683943336875789.davem@davemloft.net> <20150403154526.GB10892@google.com> X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 03 Apr 2015 09:48:57 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1375 Lines: 34 From: Bjorn Helgaas Date: Fri, 3 Apr 2015 10:45:26 -0500 > On Sun, Mar 29, 2015 at 11:32:50AM -0700, David Miller wrote: >> From: Bjorn Helgaas >> Date: Sun, 29 Mar 2015 08:30:40 -0500 >> >> > Help me understand the sparc64 situation: are you saying that BAR >> > addresses, i.e., MMIO transactions from a CPU or a peer-to-peer DMA can be >> > 64 bits, but a DMA to main memory can only be 32 bits? >> > >> > I assume this would work if we made dma_addr_t 64 bits on sparc64. What >> > would be the cost of doing that? >> >> The cost is 4 extra bytes in every datastructure, kernel wide, that >> stores DMA addresses. > > That much is fairly obvious. What I don't know is how much difference this > makes in the end. Networking drivers, and perhaps block drivers too, have a data structure for each entry in the send/receive rings for the device and these can be huge. And each ring entry stores one or more DMA addresses. Larger types mean more memory, but also more capacity cache misses in critical code paths. I'm really sorry if this isn't painfully obvious to you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/