Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932270AbWCaUGW (ORCPT ); Fri, 31 Mar 2006 15:06:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932271AbWCaUGV (ORCPT ); Fri, 31 Mar 2006 15:06:21 -0500 Received: from nommos.sslcatacombnetworking.com ([67.18.224.114]:19744 "EHLO nommos.sslcatacombnetworking.com") by vger.kernel.org with ESMTP id S932270AbWCaUGU (ORCPT ); Fri, 31 Mar 2006 15:06:20 -0500 In-Reply-To: References: <20060329225505.25585.30392.stgit@gitlost.site> <351C5BDA-D7E3-4257-B07E-ABDDCF254954@kernel.crashing.org> <200603311026.33391.netdev@axxeo.de> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Ingo Oeser" , "Chris Leech" , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Transfer-Encoding: 7bit From: Kumar Gala Subject: Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem Date: Fri, 31 Mar 2006 14:06:29 -0600 To: "Andrew Grover" X-Mailer: Apple Mail (2.746.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nommos.sslcatacombnetworking.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - kernel.crashing.org X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1072 Lines: 32 On Mar 31, 2006, at 2:04 PM, Andrew Grover wrote: > On 3/31/06, Ingo Oeser wrote: >> Kumar Gala wrote: >>> Fair, but wouldn't it be better to have the association per client. >>> >>> Maybe leave the one as a summary and have a dir per client with >>> similar stats that are for each client and add a per channel summary >>> at the top level as well. >> Such level of detail really belongs to debugging, IMHO. > [snip] > > If we implemented more stats then yes debugfs sounds like it might be > the way to go. > >> BTW: What is the actual frequency, at which such counters >> will be incremented? > > Currently the code updates these variables (kept per cpu) every time a > copy is queued. See include/linux/dmaengine.h. Might it be better to update when the transfer is done incase of an error? - kumar - 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/