| To: | Teresa Tao <Teresat@tridentmicro.com> |
|---|---|
| Subject: | Re: mmap'ed memory cacheable or uncheable |
| From: | Jun Sun <jsun@mvista.com> |
| Date: | Mon, 28 Jul 2003 14:24:01 -0700 |
| Cc: | linux-mips@linux-mips.org, jsun@mvista.com |
| In-reply-to: | <61F6477DE6BED311B69F009027C3F58403AA396F@EXCHANGE>; from Teresat@tridentmicro.com on Fri, Jul 25, 2003 at 03:52:33PM -0700 |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <61F6477DE6BED311B69F009027C3F58403AA396F@EXCHANGE> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.2.5i |
On Fri, Jul 25, 2003 at 03:52:33PM -0700, Teresa Tao wrote: > How about if I specify the following flags in my mmap routine just like what > the pgprot_noncached micro did. > pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK; > pgprot_val(vma->vm_page_prot) |= _CACHE_UNCACHED; > > Will this have kernel make the mmap'd memory non-cacheable? Or is there a > mmap non-cacheable patch? > I think this might work. Did you try it? The performance will be bad though as mmap() is used widely by userland. Jun |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [patch] Mips64 Ocelot-C and Jaguar ATX platform support, Louis Hamilton |
|---|---|
| Next by Date: | 64bit _syscall6 fix, Atsushi Nemoto |
| Previous by Thread: | RE: mmap'ed memory cacheable or uncheable, Teresa Tao |
| Next by Thread: | Re: mmap'ed memory cacheable or uncheable, Maciej W. Rozycki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |