Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Sep 2012 09:52:23 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Some busdma stats
Message-ID:  <01CF0B3B-1F24-4BAA-A662-356796DE2EDA@xcllnt.net>
In-Reply-To: <1346857799.59094.66.camel@revolution.hippie.lan>
References:  <1346689154.1140.601.camel@revolution.hippie.lan> <3AFC763F-011C-46B4-B500-FE21B704259F@bsdimp.com> <1346857799.59094.66.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sep 5, 2012, at 8:09 AM, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote:

> For that to work, the busdma implementation needs to be able to
> efficiently allocate buffers that are properly aligned and padded and
> especially that are guaranteed not to share a cache line with some other
> unrelated data.  The busdma implementation can't get those guarantees
> from malloc(9), and the alternatives (contigmalloc(), and the kmem_alloc
> family) only work in page-sized chunks.  We're asking drivers to
> allocate individual buffers of sometimes no more than a few bytes each.

In my new busdma implementation this is indeed one of the things that
get addressed. In fact, it contains a reverse mapping from the busdma
tag as we know it (representing the device's perspective) to a new
memory tag used to represent the corresponding CPU perspective. It's
the memory tag that can only be used for allocating DMA-capable
memory, as bus implementation may have non-trivial address transfor-
mations.

Note that the memory tag is where you assert CPU constraints, like
cacheline alignment.

See also:
	http://wiki.freebsd.org/UnifiedBusDma

I'm working on the projects/altix2 branch right now.

> So that's all I'm addressing in the patchset I submitted:  make sure
> that when we start fixing drivers to allocate 256 individual 16-byte IO
> descriptors that it shares with the hardware, that doesn't result in
> allocating 256 pages of memory.

Yup.

> Also, if the request is for
> BUS_DMA_COHERENT memory, make sure that doesn't result in turning off
> caching in up to 256 pages that each contain a 16 byte IO buffer and
> 4080 bytes of unrelated data.

Or worse: you end up with multiple incompatible translations for the
same physical page. This tends to cause machine checks. The busdma
infrastructure needs to maintain it's own list of physical pages and
do so per "attribute".

BTW: Are you interested in fixing bounce buffering as well?

-- 
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01CF0B3B-1F24-4BAA-A662-356796DE2EDA>