Hi.... On 9/26/09, Peter Teoh <[email protected]> wrote: > sorry for being a busy body....:-)....but hope i can contribute my 2cts... > > On Fri, Sep 25, 2009 at 12:54 PM, Mulyadi Santosa > <[email protected]> wrote: >> On 9/25/09, Jason Nymble <[email protected]> wrote: >>> For posterity, I've finally solved this issue. It ended up having >>> nothing to do with the interrupts/tasklets themselves. The driver uses >>> ioremap() to get hold of some reserved memory, and it seems from about >>> 2.6.25 onwards or so this defaults to ioremap_nocache(), so our driver >>> was doing memory operations in the tasklet on uncacheable pages. >>> Calling ioremap_cache() explicitly in the driver solved the issue >>> (nice when you can fix a perf regression of 50-100x with a single line >>> fix!). Oprofile was of tremendous help in solving this issue. >> >> Hi Jason >> >> Nice to hear you finally fix your problem. BTW, may I ask a bit about >> ioremap_cache? By using this function, it is like saying "map and >> cache these pages so next time we access them, we don't need to fetch >> them from device memory again"? CMIIW > > not really about reading.....but writing. and it is not memory > caching, but hardware caching (sounds like the same???? :-)) > Read the source: > > 279 void __iomem *ioremap_cache(resource_size_t phys_addr, > unsigned long size) > 280 { > 281 return __ioremap_caller(phys_addr, size, _PAGE_CACHE_WB, > 282 __builtin_return_address(0)); > 283 }
Ehem...I see.... however, by doing write back and hold it in page cache, it also brings advantage to read operation in near future, right? Assume we do write and few nanoseconds later we want to read it. Instead of reading through slow outer I/O bus, we read it directly from RAM...and it's faster. > it is set with WRITEBACK attribute, and write-back is a hardware > caching feature (search write-back here): > > http://en.wikipedia.org/wiki/Cache > http://en.wikipedia.org/wiki/CPU_cache > > write-through is synchronous (meaning the CPU will not execute the > next instruction, until the data on the memory bus has updated the > device in a hardware handshake protocol). but write-back is > asynchronous, for performance reason, it try to accumulate changes > before batching them in a burst of write-flush. but the delay is > usually quite small. Hm, does it do LOCK on all CPU? i.e something like doing memory barriers on all CPU ? -- regards, Mulyadi Santosa Freelance Linux trainer blog: the-hydra.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
