Re: interrupt/tasklet issue in custom driver on recent kernels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



sorry for being a busy body....:-)....but hope i can contribute my 2cts...

On Fri, Sep 25, 2009 at 12:54 PM, Mulyadi Santosa
<mulyadi.santosa@xxxxxxxxx> wrote:
> On 9/25/09, Jason Nymble <jason.nymble@xxxxxxxxx> 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 }

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.

so i supposed if u write to it, and want to use its feature almost
immediately, then no-caching mode is needed.

>
> If it is so, then logically it is the answer as it was proven by your
> experiments...
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer
> blog: the-hydra.blogspot.com
>



-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux