From owner-freebsd-arch@FreeBSD.ORG Wed Sep 5 14:30:47 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7931B1065670 for ; Wed, 5 Sep 2012 14:30:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37CC68FC0C for ; Wed, 5 Sep 2012 14:30:46 +0000 (UTC) Received: by iebc12 with SMTP id c12so1588714ieb.13 for ; Wed, 05 Sep 2012 07:30:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UF35nJTuAgSgj8n2f5foIsjGJceRm+InzWcKZykZ1hc=; b=OXhFETjFEqCq+PdSHxb/3eVl/ApycoBQgoaHG7vqmX8qYqjCPzfx/Wvm2wfLEmXplf CsHDLTXrV1nUDoUa5T5LMCY407uN3RrKK/gVayySQ8n4MPklNtf/jZ/yRNqRf+dCTXgz tdNLEfHHHT+f7onkXLDbaqYRy+YJ1+tkD7/V2AQVgN/Aq+7VuLA7oe0FXLPykEhpT4sU RKVC6gGLDI+i95L/Qc1/qBFogX5TqwLdyP8ebubls6jiLeJrxfxeczkAwM8f4dSJTcXS gjH8olRCMIF4GVxFljZiM5PS5Zv73n9CkF9l8nM9iC/PnmcfPW5soPKBHW7fmWlZHauk eO2g== Received: by 10.50.33.138 with SMTP id r10mr18327799igi.31.1346855446355; Wed, 05 Sep 2012 07:30:46 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ce10sm16435034igb.1.2012.09.05.07.30.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 07:30:45 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1346689154.1140.601.camel@revolution.hippie.lan> Date: Wed, 5 Sep 2012 08:30:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3AFC763F-011C-46B4-B500-FE21B704259F@bsdimp.com> References: <1346689154.1140.601.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkpc3uXVS7e9Qj8IXpmCtsfj1NiPz6O0NBVIeIcXw6RKCxY7cq+ZtDkFaJC+8FdXlIFVt5i Cc: freebsd-arch@freebsd.org Subject: Re: Some busdma stats X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:30:47 -0000 On Sep 3, 2012, at 10:19 AM, Ian Lepore wrote: > I decided that a good way to learn more about the busdma subsystem = would > be to actually work with the code rather than just reading it.=20 Tis true. > Regardless of whether we eventually fix every driver to eliminate > transfers that aren't aligned to cache line boundaries, or somehow > change the busdma code to automatically bounce unaligned requests, we > need efficient allocation of small buffers aligned and sized to cache > lines. The issue can't be fixed in the busdma code because partial, unaligned = transfers are fine, so long as the calling code avoids the entire cache = line during the transfer. Returning cache-line aligned buffers from the = allocator will do that, of course, but it is also valid for the code to = only use part of the buffer for the transfer. > I wrote some code to use uma(9) to manage pools of aligned > buffers based on size, and set up a pool of uncachable/coherent = buffers > and a pool of "regular memory" buffers. Very cool stats. Need to review the code you posted though... Warner