On Thu, 2006-09-14 at 12:05 +0200, Jakko Pastuchio wrote:
> Hi,
>
> first of all thank you all for the answers !
>
> On 9/14/06, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
> > > On 9/13/06, Amol Lad <amol@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > On Wed, 2006-09-13 at 12:58 +0200, Jakko Pastuchio wrote:
> > > > > I've noticed that the flush_icache_* routines on the i386
> > > > > are nothing more than an empty do{}while(0) stub.
> > > > > does anyone know why is that ?
> > > but what about events when the *physical* address space has changed
> > > (e.g. module loading) ? we still need to invalidate the cache, don't we ?
> > Nope; the x86 architecture is defined to be fully cache coherent,
> > including in this way. The only corner case I know of is if you are
> > doing self modifying code and you are changing your own/next
> > instruction.
>
> why is that ? won't the cache be automatically updated if you write to the text
> section, like it does in other cases ?
it will, but the instruction is sort of half-decoded already..
especially if you are writing to yourself, what is the cpu supposed to
do?
> > you can invalidate ALL the caches, but you generally don't need to do
> >that...
>
> how can that be done ?
the wbinv() instruction will do it.
> It seems that even flush_cache_all is empty.
again because you don't need it.
> and in general, does these flush routines invalidates the caches
> (or just flush the data to the next layer, in case of write-back caches) ?
they flush the entire hierarchy down. And can take quite a bit of time
(just think about it.. a 4Mb cache can take quite some time to flush to
ram)
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
