Date: Sun, 9 Dec 2012 17:54:07 -0700 From: Warner Losh <imp@bsdimp.com> To: Jeff Roberson <jroberson@jroberson.net> Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin <jhb@freebsd.org>, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org Subject: Re: Call for testing and review, busdma changes Message-ID: <E89ED853-3CCC-4F16-8333-89D8060D95F4@bsdimp.com> In-Reply-To: <alpine.BSF.2.00.1212090840080.4081@desktop> References: <alpine.BSF.2.00.1212080841370.4081@desktop> <1355077061.87661.320.camel@revolution.hippie.lan> <alpine.BSF.2.00.1212090840080.4081@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ looks like Ian answered the other questions ]] On Dec 9, 2012, at 11:48 AM, Jeff Roberson wrote: >>> The next step is to allow for dma loading of physical addresses. = This >>> will permit unmapped I/O. Which is a significant performance = optimization >>> targeted for 10.0. >>=20 >> This sounds scary for arm and mips, or more specifically for VIVT = cache >> platforms that can only do a sync based on virtual addresses. Can = you >> talk some more about the plans for this? >=20 > It will be for addresses which were never mapped into kva. To support = unmaapped io. There will only be a need for bounce pages, no syncing. If there's a virtual mapping at all for the page (not just a kva), then = we need to flush/invalidate cache for those pages for safety unless we = know for sure there's nothing in the cache. It these are pages that = have never been mapped (say for zero copy between storage and network = controllers), then there won't be a problem. The whole reason for cache = jockeying is to make sure that any pending writes to the data are = flushed, and that any cached notion of the pages are invalidated once = the read is done. This is more important for mbuf operations, = operations with the USB stack or anything else that marshals data it = generates to be consumed by the stack/hardware. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E89ED853-3CCC-4F16-8333-89D8060D95F4>