INVD instruction in x86, is that really needed?

[Database Administrator]

80486 and later has INVD(invalidate data cache) and WBINVD(write back
and invalidate data cache) instructions, and i'm puzzled about why
these instructions come into existence and are that really needed?

And i also find in PowerPC ISA that there are DCBI(data cache block
invalidate) and ICBI(instruction cache block invalidate) instructions,
and i'm further puzzled by why it is necessary to design an
instruction to invalidate instruction cache?

While in MIPS IV ISA, i cannot find similar instructions to those
mentioned above.

i'm really confused. And can anybody explain it? any comment will be
appreciated.

thx in advance.

Sean.

[Database Administrator]

On 13 Apr., 18:04, "Sean" wrote:
> 80486 and later has INVD(invalidate data cache) and WBINVD(write back
> and invalidate data cache) instructions, and i'm puzzled about why
> these instructions come into existence and are that really needed?
>
> And i also find in PowerPC ISA that there are DCBI(data cache block
> invalidate) and ICBI(instruction cache block invalidate) instructions,
> and i'm further puzzled by why it is necessary to design an
> instruction to invalidate instruction cache?
>
> While in MIPS IV ISA, i cannot find similar instructions to those
> mentioned above.
>

Though, this sounds like homework to me, here are two situations, in
which they might be needed:
One situation is, when the virtual addresses change, i.e. when the
page table is modified.
When a certain memory item is removed from the program's memory its
content is obviously
not required any longer, and no write-backs are needed. If it will be
used, but at a different address,
than you need to write back, before invalidating the cache.


Another situation is IO when it is not cache-coherent attached, at
least with respect to read from memory by an
IO device. Assume that an application has written data to a certain
address and this address is handled
to a network adatapter which will read data from memory for transfer.
In that case, you want to be sure, that the data is in memory before
the network adapter will read it.
In case of sending, you need to write back before flushing, in case of
a receive buffer, you also need to flush the cache, to make sure, that
the received data will not be overwritten by the processor when
casting out that cache line later. No write-back is needed in this
case.

Andreas

[Database Administrator]

On Fri, 13 Apr 2007 09:04:41 -0700, Sean wrote:

> 80486 and later has INVD(invalidate data cache) and WBINVD(write back
> and invalidate data cache) instructions, and i'm puzzled about why
> these instructions come into existence and are that really needed?
>
> And i also find in PowerPC ISA that there are DCBI(data cache block
> invalidate) and ICBI(instruction cache block invalidate) instructions,
> and i'm further puzzled by why it is necessary to design an
> instruction to invalidate instruction cache?

any number of reasons...
Running benchmarks?
Characterising or testing the memory systems?
Initialisation to a known state?
Certain exotic programming techniques?
Remapping virtual memory?
Operating non-coherent I/O?
Powering down the processor (keeping state in RAM)?
Working around bugs in external hardware?
--
Anon

[Database Administrator]

"Sean" writes:
>80486 and later has INVD(invalidate data cache) and WBINVD(write back
>and invalidate data cache) instructions, and i'm puzzled about why
>these instructions come into existence and are that really needed?

Not really sure about that. Maybe it's there for hardware that does
not ensure cache consistency (normally IA-32 multi-processor hardware
does this in hardware).

>And i also find in PowerPC ISA that there are DCBI(data cache block
>invalidate) and ICBI(instruction cache block invalidate) instructions,
>and i'm further puzzled by why it is necessary to design an
>instruction to invalidate instruction cache?

The PowerPC does not guarantee hardware consistency between data and
instruction caches, so if a program writes instructions, it has to do
some magic incantations (involving various cache flush and invalidate
instructions, plus sequencing; one of these is icbi) in order to
guarantee that they are consistent.

Unfortunately, these instructions are only half-architected, so any
such sequence comes with a caveat that it may not work on all
machines; and the invalidation block size is not specified, either.

>While in MIPS IV ISA, i cannot find similar instructions to those
>mentioned above.

Yes, MIPS is extremely poor in that respect. No hardware cache
consistency (at least for the I-cache), and no architected
instructions for enforcing cache consistency in software. So what is
going on there is that the application has to do some system call, and
the OS then uses some implementation-specific instructions that do
what e.g., ICBI does in the PowerPC architecture.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

[Database Administrator]

acd wrote:

> One situation is, when the virtual addresses change, i.e. when the
> page table is modified.

Physically-indexed caches do not require invalidation in this case.
As the name self-explains, it works with physical addresses, i.e.
does not know anything about virtual mappings. You probably
refer to the invlpg instruction, which indeed is used during remapping.

> When a certain memory item is removed from the program's memory its
> content is obviously not required any longer

But the cache update protocol itself will evict the old lines.
There is no need to explicitly invalidate a line, not to mention
entire cache (which actually (wb)invd does...).

> Another situation is IO when it is not cache-coherent attached, at
> least with respect to read from memory by an
> IO device.

Then you simply map it as "uncached" (or use a MTRR)
and no coherence protocol will be involved.

> In that case, you want to be sure, that the data is in memory before
> the network adapter will read it.

Then use "uncached" or "write combining" modes,
don't raise havoc invalidating entire cache memory.

Best regards
Piotr Wyderski

[Database Administrator]

"Piotr Wyderski" writes:

>> Another situation is IO when it is not cache-coherent attached, at
>> least with respect to read from memory by an
>> IO device.

>Then you simply map it as "uncached" (or use a MTRR)
>and no coherence protocol will be involved.

Simple, sure. Efficient, too? Please talk about file cache / disk I/O,
and zero copy network stack processing, when done un uncached memory.

>> In that case, you want to be sure, that the data is in memory before
>> the network adapter will read it.

>Then use "uncached" or "write combining" modes,
>don't raise havoc invalidating entire cache memory.

What operating system kept its network packet buffers uncached in this way?

best regards
Patrick

[Database Administrator]

On Apr 14, 5:52 am, "Piotr Wyderski" ii.uni.wroc.pl> wrote:
> acd wrote:
> > One situation is, when the virtual addresses change, i.e. when the
> > page table is modified.
>
> Physically-indexed caches do not require invalidation in this case.
> As the name self-explains, it works with physical addresses, i.e.
> does not know anything about virtual mappings. You probably
> refer to the invlpg instruction, which indeed is used during remapping.
>
> > When a certain memory item is removed from the program's memory its
> > content is obviously not required any longer
>
> But the cache update protocol itself will evict the old lines.
> There is no need to explicitly invalidate a line, not to mention
> entire cache (which actually (wb)invd does...).
>
> > Another situation is IO when it is not cache-coherent attached, at
> > least with respect to read from memory by an
> > IO device.
>
> Then you simply map it as "uncached" (or use a MTRR)
> and no coherence protocol will be involved.
>
> > In that case, you want to be sure, that the data is in memory before
> > the network adapter will read it.
>
> Then use "uncached" or "write combining" modes,
> don't raise havoc invalidating entire cache memory.
>
> Best regards
> Piotr Wyderski

I at first thought similar to Piotr did. however, u'v give me far more
reasons as i ever expected.

To be honest, i lack kind of knowledge on OS or demands out of
application like network. Though, i can not understand all of needs
such as runtime-code generation or just-intime-compilation, reasons
like "initialization cache to a known state at startup" and "flush
cache at powering down" and i/o operation of coz, have convinced me of
the necessity of this kinda instructions.

And i have to say sorry that i find such alike instruction in MIPS ISA
also - CACHE instruction/CacheOp, they are designed to operate caches.

I really hope cache can be totally transparent to programmers and all
kind of intricate operations are guaranteed by hardware...but in fact,
it seems that attentions should be paid in order to get the right
operating result!

Sean

[Database Administrator]

Patrick Schaaf wrote:

> Simple, sure. Efficient, too? Please talk about file cache / disk I/O,
> and zero copy network stack processing, when done un uncached memory.

Consistency or efficiency, the choice is up to you. Write-through
is a good compromise in most situations. The choice of caching
mode reflects the abilities of the underlying hardware, it is not an
OS-dependent feature.

> What operating system kept its network packet buffers uncached in this
> way?

Which operating system uses wbinvd to flush its entire multilevel
cache hierarchy (0.5...4 megabytes) just to send a UDP datagram
or to remap a physical memory frame...?

Best regards
Piotr Wyderski