From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 18:08:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01209106566B for ; Tue, 4 Sep 2012 18:08:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A44F18FC1D for ; Tue, 4 Sep 2012 18:08:38 +0000 (UTC) Received: by yenl7 with SMTP id l7so1364396yen.13 for ; Tue, 04 Sep 2012 11:08:37 -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=z8YQg6niwhc8cvqOy/Z/95tOdtZM0Zm2d2lfuHAOczA=; b=JJZ2KKt0qayipCzkvZrHq3wJXJMKZ/ogPyfODmtxhnZvdc0De7SHod2HAtON0W7g5s jCNuIClLFQ6zCplAsc49zmOSVgOBv5TQHCxKTx5KaJDaA9sJBlXH+nWNPYS5kpYqJc4j EuqQkg6sEi9/QcSFZVSWfAfrvmHihL3q6T2xfeqJIqCHlK4GSM5rVOhKsRNI6VQ072hL fOdxWXFJUKkdXeZt+3VFoYP325nxWkpGiboliI+bFZEriF7wfxe5if9iJxPqGm4djh3k zDpWsR4vEo1xhj2d3jB0C5ow7hBsDxkgb7BqJHk6/lDlGnxVHZIjelVzpmt394DI5n9N MMUg== Received: by 10.236.74.37 with SMTP id w25mr19454277yhd.30.1346782117695; Tue, 04 Sep 2012 11:08:37 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id b46sm31160808yhm.3.2012.09.04.11.08.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 11:08:36 -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: <1346781390.1140.641.camel@revolution.hippie.lan> Date: Tue, 4 Sep 2012 12:08:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2C9793BE-70B0-4A18-B5D2-FBA8C63A4552@bsdimp.com> References: <1346777897.1140.633.camel@revolution.hippie.lan> <1346781390.1140.641.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnM5xJrCx1ZVR6MfHSs8iMIH9s0L1nbO+s2qKR7qkCyIahdm7Nr9GLjJEgMyo4tqpMnCRte Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:08:39 -0000 On Sep 4, 2012, at 11:56 AM, Ian Lepore wrote: > On Tue, 2012-09-04 at 12:40 -0500, Mark Tinguely wrote: >> On Tue, Sep 4, 2012 at 11:58 AM, Ian Lepore >> wrote: >> How about having a per processor cache line definition rather than = using: >>=20 >> +#define MIN_ZONE_BUFSIZE 32 >>=20 >> For those archs that have a 64 byte cache line. >>=20 >> I like the separation of the regular and BUS_DMA_COHERENT or >> BUS_DMA_NOCACHE. I never liked turning the cache off the entire page >> for a few DMA buffers. >>=20 >> --Mark. >=20 > The code in busdma_bufalloc.c (where that constant appears) knows > nothing about architecture cache line sizes, that info has to be = passed > in to the create call as the minimum_alignment parameter. >=20 > The point of that constant is to enforce internal limits in the > implementation... if the caller passes in a minimum_alignment size = less > than 32, it will still use 32 as the smallest buffer size in the = cache, > purely because it only allocates enough slots in the array to handle > log2(PAGE_SIZE) - log2(MIN_ZONE_BUFSIZE) + 1 zones, but you can't use > log2() in a compile time constant expression, so things are a bit > hand-tuned, and there's some code for sanity-enforcement. kassert then, because we'll have this problem all over again. Would be = nice if we could make those arrays dynamically sized though... Will read the rest of the patch later today... Warner