| To: | "Kevin D. Kissell" <kevink@mips.com> |
|---|---|
| Subject: | Re: __flush_cache_all() miscellany |
| From: | Ralf Baechle <ralf@oss.sgi.com> |
| Date: | Wed, 29 May 2002 14:28:55 -0700 |
| Cc: | Justin Carlson <justinca@cs.cmu.edu>, linux-mips@oss.sgi.com |
| In-reply-to: | <01cb01c20754$4c14e400$10eca8c0@grendel>; from kevink@mips.com on Wed, May 29, 2002 at 11:03:20PM +0200 |
| References: | <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> <1022700389.7644.155.camel@ldt-sj3-022.sj.broadcom.com> <01cb01c20754$4c14e400$10eca8c0@grendel> |
| Sender: | owner-linux-mips@oss.sgi.com |
| User-agent: | Mutt/1.2.5.1i |
On Wed, May 29, 2002 at 11:03:20PM +0200, Kevin D. Kissell wrote: > While trampolines, breakpointing and JITing are the main > uses of user-mode cache manipulation (drivers are a whole > 'nother story), we really should have distinct capabilities for > I-stream modification and for explicit synchronizations of > the data storage hierarchy, for non-coherent multiprocessors > and user-manipulated DMA buffers. As to whether > those capabilities should be distinguished by system > call (sysmips vs. cacheflush) or by parameter to the > same system call, I don't have enough data to form > an opinion at this point. It should clearly be cacheflush(2); sysmips(2) is too coarse, too ugly interface. Another thing we'll still have to implement is the cachectl(2) syscall; for certain systems and applications fine control of the caching mode use for a memory mapping may result in major performance improvments. Ralf |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: __flush_cache_all() miscellany, Ralf Baechle |
|---|---|
| Next by Date: | Re: __flush_cache_all() miscellany, Ralf Baechle |
| Previous by Thread: | Re: __flush_cache_all() miscellany, Kevin D. Kissell |
| Next by Thread: | Re: __flush_cache_all() miscellany, Ralf Baechle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |