Date: Thu, 13 Feb 2003 23:30:38 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Eric Anholt <eta@lclark.edu> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/modules Makefile Message-ID: <20030214073038.GA2349@athlon.pn.xcllnt.net> In-Reply-To: <1045206256.84507.99.camel@leguin> References: <20030213223058.769DA2A8C1@canning.wemm.org> <1045185451.11981.17.camel@leguin> <20030214023218.GA1573@athlon.pn.xcllnt.net> <1045194133.11981.87.camel@leguin> <20030214043028.GA1797@athlon.pn.xcllnt.net> <1045200753.84507.54.camel@leguin> <20030214061708.GA2109@athlon.pn.xcllnt.net> <1045206256.84507.99.camel@leguin>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 13, 2003 at 11:04:17PM -0800, Eric Anholt wrote: > > Not sure quite what you mean by SGM. A term from the AGP specification. It means the system memory used by the graphics controller alongside its local graphics memory (LGM) or LFB. It's the memory you address through the GART. > Also a little confused by the ia64 thing. How is that going to behave > differently than an i386 then? Not reorder writes to the bus? You can set attributes on virtual addresses. The attributes are on the regions to be precise. One of the attributes is the cachability attr. If a region is marked as uncacheable, the processor will not cache read/writes in that region and cache flushes are unnecessary. Memory ordering is weak anyway, so reordering can still happen. I don't think you have that level of control on i386. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030214073038.GA2349>