Re: Missing cache flush.
David S. Miller writes:
> David Woodhouse writes:
>>> Call it flush_ecache_full() or something.
>>
>> Strange name. Why? How about __flush_cache_range()?
>
> How about flush_cache_range_force() instead?
>
> I want something in the name that tells the reader "this flushes
> the caches, even though under every other ordinary circumstance
> you would not need to".
"flush" means what to you?
write-back
write-back-and-invalidate
discard-and-invalidate
All 3 behaviors are useful to me, and a few more. I've been
using chunks of PowerPC assembly. Using PowerPC mnemonics...
dcba -- allocate a cache block with undefined content
dcbf -- write to RAM, then invalidate ("data cache block flush")
dcbi -- invalidate, discarding any data
dcbst -- initiate write if dirty
dcbt -- prefetch, hinting about future load instructions
dcbtst -- prefetch, hinting about future store instructions
dcbz -- allocate and zero a cache block (cacheable mem only!)
So dcbf_range() and dcbi_range() sound good to me. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David S. Miller writes: David Woodhouse writes: Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? How about flush_cache_range_force() instead? I want something in the name that tells the reader this flushes the caches, even though under every other ordinary circumstance you would not need to. flush means what to you? write-back write-back-and-invalidate discard-and-invalidate All 3 behaviors are useful to me, and a few more. I've been using chunks of PowerPC assembly. Using PowerPC mnemonics... dcba -- allocate a cache block with undefined content dcbf -- write to RAM, then invalidate (data cache block flush) dcbi -- invalidate, discarding any data dcbst -- initiate write if dirty dcbt -- prefetch, hinting about future load instructions dcbtst -- prefetch, hinting about future store instructions dcbz -- allocate and zero a cache block (cacheable mem only!) So dcbf_range() and dcbi_range() sound good to me. :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tuesday 05 June 2001 14:57, Chris Wedgwood wrote: > I don't know about the CRIS (never heard of it, what is it?) I wondered about that too. From Documentation/cris: What is CRIS ? -- CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU architecture in Axis Communication AB's range of embeddedn etwork CPU's, called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for 'Linux' because the chip was designed to be a good host for the Linux operating system. Interesting, huh? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, Jun 05, 2001 at 10:29:28AM +0200, Ingo Molnar wrote: > > - even when it works, it is necessarily very very very slow. Not to be > >used lightly. As you can imagine, the work-around is even slower. > > i've measured it once, IIRC it was around 10-15 millisecs on normal > pentiums, so while it's indeed the slowest x86 instruction on the planet, > it's still perhaps acceptable for hot-swapping ECC RAM. I can already hear the realtime crowd bitch ... Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Wed, Jun 06, 2001 at 12:57:03AM +1200, Chris Wedgwood wrote: > I don't know about the CRIS (never heard of it, what is it?), but on > an Athlon when benchmarking stuff, I could still see L1 cache hits > from data that was 15 seconds old under certain work-loads (obviously > not gcc!). Does anyone know how old something may exisit in cache > before being written back to RAM? I know of no architecture that has a time limit that after which's expire caches get written back to memory. In other words cache lines may stay dirty for an indefinate time if things are just right. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Bjorn Wesen wrote: > > I'd agree that to be really certain, a "flush_dcache()" function > should be implemented and used when an erase finishes. Like David Miller > wrote somewhere in the thread, one way is to use your knowledge of the > arch's cache and do suitable dummy accesses to flush it, if there is no > explicit command to do it. But that's just up to the arch coders.. > Here's a stupid question: Are there any processors out there that have a cache but no explicit cache-flush command? If not (i.e. no such "funny" processors), then what's wrong with the arch dependent include through a define to execute the arch specific asm command? The only issue (besides knowing the cache size at run time) that I can think about the "dummy" eviction scheme is that you now need to xfer potentially 3 times the cache size data to and from memory: #1. The dummy read #2. The eviction of the entire cache data being evicted #3. The refilling of the cache with good data again, as the dummy data cannot really represent anything useful. Is my thinking here completely non coherent with others? ;) Vipin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: > How about flush_cache_range_force() instead? > I want something in the name that tells the reader "this flushes the > caches, even though under every other ordinary circumstance you would > not need to". OL, then. I would have thought it made more sense to have the flush_dcache_range() unconditionally do what its name implies, and to have a separate flush_dcache_range_for_dma() function which is optional. But that decision was already made - I suppose we can't change the semantics now. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: > > Call it flush_ecache_full() or something. > > Strange name. Why? How about __flush_cache_range()? How about flush_cache_range_force() instead? I want something in the name that tells the reader "this flushes the caches, even though under every other ordinary circumstance you would not need to". Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: > David Woodhouse writes: > > What shall we call this function? The intuitive "flush_dcache_range" > > appears to have already been taken. > Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Possibly saying something extremly stupid here,
how about simply "fakewriting" 0xFF to the flash
after an erase to update any caches?
> 2. Flash. A few writes of magic data to magic addresses and a whole erase
>block suddenly contains 0xFF. The CPU doesn't notice that either.
do_erase_stuff();
/* While verifying, update cache */
for (address = adr; address < (adr + size); address++) {
if ((verify = map->read8(map, address)) != 0xFF) {
error = 1;
break;
}
/* "Fake" write 0xFF's to the erased sector so that
caches are updated
* after we verified that uncached data is ok
*/
*(unsigned char*)CACHED(address) = 0xFF;
}
/Johan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, 5 Jun 2001, David Woodhouse wrote: > The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached > mapping of the flash chips for bulk reads, but obviously an uncached mapping > for sending commands and reading status when we're actually writing to or > erasing parts of the chip. > > However, it fails to flush the dcache for the range used when the flash is > accessed through the uncached mapping. So after an erase or write, we may > read old data from the cache for the changed area. I'll start by saying that axisflashmap.c was not meant to be used by any other archs, that's why it's in arch/cris. But if anyone find it useful, that's great. Just be aware that it's not _designed_ for general use and something like this might be just what that might mean. CRIS is cache coherent just like the x86 cache and does not need any explicit cache flushes for the write case. Even when doing cache bypass writing, if a cacheline already exist with the referenced memory, the cacheline is updated. In the erase case though, yes there should be a flush. However during the 1-2 seconds it takes to erase a sector, you can with very high certainity guarantee that the direct-mapped unified 8 kB cache on the CRIS is flushed from any flash references at all.. I mean, it's one-way associative, during 1-2 seconds it executes potentially 200 million instructions. So we haven't really bothered to think about the problem.. For other CPU's it might be more dangerous, although I don't hold my breath.. 1-2 seconds is a long time when talking about L1 caches. > However, I can't see a cache operation which performs this function. > flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most > architectures. On other architectures, there's dma_cache_wback_inv(), but > that also seems to be a NOP on i386, to pick a random example. I'd agree that to be really certain, a "flush_dcache()" function should be implemented and used when an erase finishes. Like David Miller wrote somewhere in the thread, one way is to use your knowledge of the arch's cache and do suitable dummy accesses to flush it, if there is no explicit command to do it. But that's just up to the arch coders.. -bw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: > What shall we call this function? The intuitive "flush_dcache_range" appears > to have already been taken. Call it flush_ecache_full() or something. Many architectures need to implement this anyways if they have parity error exception handling. Most platforms sadly do not. Sparc64 is one of the exceptions here... Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On 4 Jun 2001, Linus Torvalds wrote: > - even when it works, it is necessarily very very very slow. Not to be >used lightly. As you can imagine, the work-around is even slower. i've measured it once, IIRC it was around 10-15 millisecs on normal pentiums, so while it's indeed the slowest x86 instruction on the planet, it's still perhaps acceptable for hot-swapping ECC RAM. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On 4 Jun 2001, Linus Torvalds wrote: - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. i've measured it once, IIRC it was around 10-15 millisecs on normal pentiums, so while it's indeed the slowest x86 instruction on the planet, it's still perhaps acceptable for hot-swapping ECC RAM. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, 5 Jun 2001, David Woodhouse wrote: The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached mapping of the flash chips for bulk reads, but obviously an uncached mapping for sending commands and reading status when we're actually writing to or erasing parts of the chip. However, it fails to flush the dcache for the range used when the flash is accessed through the uncached mapping. So after an erase or write, we may read old data from the cache for the changed area. I'll start by saying that axisflashmap.c was not meant to be used by any other archs, that's why it's in arch/cris. But if anyone find it useful, that's great. Just be aware that it's not _designed_ for general use and something like this might be just what that might mean. CRIS is cache coherent just like the x86 cache and does not need any explicit cache flushes for the write case. Even when doing cache bypass writing, if a cacheline already exist with the referenced memory, the cacheline is updated. In the erase case though, yes there should be a flush. However during the 1-2 seconds it takes to erase a sector, you can with very high certainity guarantee that the direct-mapped unified 8 kB cache on the CRIS is flushed from any flash references at all.. I mean, it's one-way associative, during 1-2 seconds it executes potentially 200 million instructions. So we haven't really bothered to think about the problem.. For other CPU's it might be more dangerous, although I don't hold my breath.. 1-2 seconds is a long time when talking about L1 caches. However, I can't see a cache operation which performs this function. flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most architectures. On other architectures, there's dma_cache_wback_inv(), but that also seems to be a NOP on i386, to pick a random example. I'd agree that to be really certain, a flush_dcache() function should be implemented and used when an erase finishes. Like David Miller wrote somewhere in the thread, one way is to use your knowledge of the arch's cache and do suitable dummy accesses to flush it, if there is no explicit command to do it. But that's just up to the arch coders.. -bw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Possibly saying something extremly stupid here,
how about simply fakewriting 0xFF to the flash
after an erase to update any caches?
2. Flash. A few writes of magic data to magic addresses and a whole erase
block suddenly contains 0xFF. The CPU doesn't notice that either.
do_erase_stuff();
/* While verifying, update cache */
for (address = adr; address (adr + size); address++) {
if ((verify = map-read8(map, address)) != 0xFF) {
error = 1;
break;
}
/* Fake write 0xFF's to the erased sector so that
caches are updated
* after we verified that uncached data is ok
*/
*(unsigned char*)CACHED(address) = 0xFF;
}
/Johan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Bjorn Wesen wrote: I'd agree that to be really certain, a flush_dcache() function should be implemented and used when an erase finishes. Like David Miller wrote somewhere in the thread, one way is to use your knowledge of the arch's cache and do suitable dummy accesses to flush it, if there is no explicit command to do it. But that's just up to the arch coders.. Here's a stupid question: Are there any processors out there that have a cache but no explicit cache-flush command? If not (i.e. no such funny processors), then what's wrong with the arch dependent include through a define to execute the arch specific asm command? The only issue (besides knowing the cache size at run time) that I can think about the dummy eviction scheme is that you now need to xfer potentially 3 times the cache size data to and from memory: #1. The dummy read #2. The eviction of the entire cache data being evicted #3. The refilling of the cache with good data again, as the dummy data cannot really represent anything useful. Is my thinking here completely non coherent with others? ;) Vipin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Wed, Jun 06, 2001 at 12:57:03AM +1200, Chris Wedgwood wrote: I don't know about the CRIS (never heard of it, what is it?), but on an Athlon when benchmarking stuff, I could still see L1 cache hits from data that was 15 seconds old under certain work-loads (obviously not gcc!). Does anyone know how old something may exisit in cache before being written back to RAM? I know of no architecture that has a time limit that after which's expire caches get written back to memory. In other words cache lines may stay dirty for an indefinate time if things are just right. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, Jun 05, 2001 at 10:29:28AM +0200, Ingo Molnar wrote: - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. i've measured it once, IIRC it was around 10-15 millisecs on normal pentiums, so while it's indeed the slowest x86 instruction on the planet, it's still perhaps acceptable for hot-swapping ECC RAM. I can already hear the realtime crowd bitch ... Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tuesday 05 June 2001 14:57, Chris Wedgwood wrote: I don't know about the CRIS (never heard of it, what is it?) I wondered about that too. From Documentation/cris: What is CRIS ? -- CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU architecture in Axis Communication AB's range of embeddedn etwork CPU's, called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for 'Linux' because the chip was designed to be a good host for the Linux operating system. Interesting, huh? -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: How about flush_cache_range_force() instead? I want something in the name that tells the reader this flushes the caches, even though under every other ordinary circumstance you would not need to. OL, then. I would have thought it made more sense to have the flush_dcache_range() unconditionally do what its name implies, and to have a separate flush_dcache_range_for_dma() function which is optional. But that decision was already made - I suppose we can't change the semantics now. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: David Woodhouse writes: What shall we call this function? The intuitive flush_dcache_range appears to have already been taken. Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: Call it flush_ecache_full() or something. Strange name. Why? How about __flush_cache_range()? How about flush_cache_range_force() instead? I want something in the name that tells the reader this flushes the caches, even though under every other ordinary circumstance you would not need to. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: What shall we call this function? The intuitive flush_dcache_range appears to have already been taken. Call it flush_ecache_full() or something. Many architectures need to implement this anyways if they have parity error exception handling. Most platforms sadly do not. Sparc64 is one of the exceptions here... Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
In article <[EMAIL PROTECTED]>, Chris Wedgwood <[EMAIL PROTECTED]> wrote: >On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote: > >The x86 doesn't have dumb caches, therefore it really doesn't >need to flush anything. Maybe a mb(), but that is it. > >What if the memory is erased underneath the CPU being aware of this? >In such a way ig generates to bus traffic... Doing bank switching etc is outside the scope of the current DMA cache flush macros - they are there only for "sane" cache coherency issues, not to be used as generic "we have to flush the cache because we went behind the back of the CPU and switched a bank of memory around". You will have to come up with some new primitive for this. The x86 has the "wbinval" instruction, although it should be noted that - it is buggy and will lock up some CPU's. Use with EXTREME CAUTION. Intel set a special field in the MP table for whether wbinval is usable or not, and you can probably find their errata on which CPU's it doesn't work on (I think it was some early PPro steppings). When wbinval doesn't work, there's another strategy to flush the cache, but I forget what it was. It was something ridiculous like reading in a few megabytes of memory from consecutive physical addresses to make sure that the cache has been replaced. - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. On the whole, I would suggest avoiding this like the plague, and just marking such memory to be non-cacheable, regardless of whether there is a performance impact or not. If you mark it write-combining and speculative, it's going to perform a bit better. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: > > What should it do on i386? mb()? > > For it to have any use in the situation I described, it would need to > writeback and invalidate the dcache for the affected range. It doesn't seem > to do so, so it seems that it isn't what I require. It only needs to do that on cpus where the cache is not consistent with the rest of the system. x86 caches are fully consistent with the rest of the system, thus no flushing necessary. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Jeff Garzik writes: > David Woodhouse wrote: > > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very > > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on > > i386 shows that it doesn't do what's required anyway. > > What should it do on i386? mb()? The x86 doesn't have dumb caches, therefore it really doesn't need to flush anything. Maybe a mb(), but that is it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: > > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem > > very helpful - it's very PCI-specific, and a quick perusal of > > pci_dma_sync() on i386 shows that it doesn't do what's required anyway. > What should it do on i386? mb()? For it to have any use in the situation I described, it would need to writeback and invalidate the dcache for the affected range. It doesn't seem to do so, so it seems that it isn't what I require. The situation is simple - I have a paged RAM setup and I need it cached. All I want to do is flush and invalidate the cache when I'm about to waggle whatever I/O ports I waggle to change pages. There are other situations in which I need the cache flushed, but the above is one of the simplest. Even flush_page_to_ram() doesn't seem to do what its name implies, on most architectures. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse wrote: > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on > i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? -- Jeff Garzik | Echelon words of the day, from The Register: Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26 MandrakeSoft | Steak Knife Kill the President anarchy echelon | nuclear assassinate Roswell Waco World Trade Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse wrote: I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? -- Jeff Garzik | Echelon words of the day, from The Register: Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26 MandrakeSoft | Steak Knife Kill the President anarchy echelon | nuclear assassinate Roswell Waco World Trade Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
[EMAIL PROTECTED] said: I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? For it to have any use in the situation I described, it would need to writeback and invalidate the dcache for the affected range. It doesn't seem to do so, so it seems that it isn't what I require. The situation is simple - I have a paged RAM setup and I need it cached. All I want to do is flush and invalidate the cache when I'm about to waggle whatever I/O ports I waggle to change pages. There are other situations in which I need the cache flushed, but the above is one of the simplest. Even flush_page_to_ram() doesn't seem to do what its name implies, on most architectures. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Jeff Garzik writes: David Woodhouse wrote: I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? The x86 doesn't have dumb caches, therefore it really doesn't need to flush anything. Maybe a mb(), but that is it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
In article [EMAIL PROTECTED], Chris Wedgwood [EMAIL PROTECTED] wrote: On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote: The x86 doesn't have dumb caches, therefore it really doesn't need to flush anything. Maybe a mb(), but that is it. What if the memory is erased underneath the CPU being aware of this? In such a way ig generates to bus traffic... Doing bank switching etc is outside the scope of the current DMA cache flush macros - they are there only for sane cache coherency issues, not to be used as generic we have to flush the cache because we went behind the back of the CPU and switched a bank of memory around. You will have to come up with some new primitive for this. The x86 has the wbinval instruction, although it should be noted that - it is buggy and will lock up some CPU's. Use with EXTREME CAUTION. Intel set a special field in the MP table for whether wbinval is usable or not, and you can probably find their errata on which CPU's it doesn't work on (I think it was some early PPro steppings). When wbinval doesn't work, there's another strategy to flush the cache, but I forget what it was. It was something ridiculous like reading in a few megabytes of memory from consecutive physical addresses to make sure that the cache has been replaced. - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. On the whole, I would suggest avoiding this like the plague, and just marking such memory to be non-cacheable, regardless of whether there is a performance impact or not. If you mark it write-combining and speculative, it's going to perform a bit better. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
David Woodhouse writes: What should it do on i386? mb()? For it to have any use in the situation I described, it would need to writeback and invalidate the dcache for the affected range. It doesn't seem to do so, so it seems that it isn't what I require. It only needs to do that on cpus where the cache is not consistent with the rest of the system. x86 caches are fully consistent with the rest of the system, thus no flushing necessary. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
