Hi Ralf, there is one more good reason to ... : the Impact Xserver needs to do a cacheflush(a,w,DCACHE) as part of the refresh-sequence. And hence requires a sys_cacheflush, let's say, more conforming to the man-page (or some disgusting new ioctl in the Impact kernel-driver to do an equivalent operation ;-) kind regards :-) On Wed, 11 Feb 2009, Ralf Baechle wrote: > Date: Wed, 11 Feb 2009 13:16:49 +0000 > From: Ralf Baechle <ralf@xxxxxxxxxxxxxx> > To: naresh kamboju <naresh.kernel@xxxxxxxxx> > Cc: linux-mips@xxxxxxxxxxxxxx > Subject: Re: cacheflush system call-MIPS > > On Tue, Feb 10, 2009 at 08:46:58PM +0530, naresh kamboju wrote: > > > Hi Mr. Ralf, > > > > I have tried to test cacheflush system call to generate EINVAL > > > > on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel. > > > > I have referred latest Man pages there is a bug column. > > > > Please let me know whether this is bug in source code or in the man page. > > > > (arch/mips/mm/cache.c) > > The answer is probably a bit of both. The API and error behaviour was > defined by the earlier MIPS UNIX variant RISC/os or possibly even earlier. > > Gcc relies on the existence of this syscall - or rather a library > function which usually will be implemented to execute this syscall because > the operating requires kernel priviledges - so Linux had to get an > implementation as well. > > Now in practice there is only one good reason to perform explicit > cacheflushes from userspace and that's to ensure I-cache coherency and > that's the one thing the Linux implementation of cacheflush(2) is trying > to do. Therefore the implementation ignores the cache argument and > will instead perform whatever is necessary to guarantee I-cache coherency - > whatever this means on a particlar implementation. > > Similarly the implementation won't verify that every byte of the range > is accessible. For a large range it instead may choose to perform a full > writeback / invalidation of some or all parts of the cache hierarchy > which might mean there will not be an error return even though part of > the address space may not be accessible. > > Talking about bugs - the "BUGS" section of the man page is wrong. A full > cacheflush is only performed if this is considered to be faster than a > cacheline-by-cacheline flush. > > Ralf > >
