From owner-freebsd-mips@FreeBSD.ORG Tue Sep 4 18:08:39 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 013F4106566C for ; Tue, 4 Sep 2012 18:08:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A45638FC1E for ; Tue, 4 Sep 2012 18:08:38 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1353467ggn.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=gQ15qcp9zqG5w2BXy2/+OC6rzb3LY33i/vA2jovTg0VvpoGleqN6Me0LHzYERtSvI3 l0DpIpYW0EpNjDjlq9NAlSqk5qooNLKUnufptcJA3LYHlRLKwG33zb/h6GaK8VdMi5aE elpX9QqhSpkMvgNRs+Opucn6O/BEYPXrFfpPO/BCS0eaLRfvvPfkwk5goFVYdncGkpdv aIWbq5xlt08jI87WJLim/cr3wEUeEJRHbIo+5/r9tZxwL1zs9QNSjcCBWSd4/lExs9zi TYP4REJ8Q1loeUJkQ63KcHeuage7YNMZZ2zjjEClrkUJcb+Bn3yRTLqWUGYdGlBW6TDI yBPQ== 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: ALoCoQmhhboVEATJAQMsu5EokbDs8nJtwBhu7H4x9+69kZvTL4r8WxF2DxXepP3Zinl6S6dCJr48 Cc: freebsd-arm@freebsd.org, Mark Tinguely , freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS 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