linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: bill4carson@gmail.com (bill4carson)
To: linux-arm-kernel@lists.infradead.org
Subject: Query about: ARM11 MPCore: preemption/task migration cache coherency
Date: Thu, 31 May 2012 11:11:46 +0800	[thread overview]
Message-ID: <4FC6E172.4080601@gmail.com> (raw)
In-Reply-To: <20120531030016.GB29372@mbp>



On 2012?05?31? 11:00, Catalin Marinas wrote:
> Hi,
>
> On Wed, May 30, 2012 at 11:01:59AM +0100, bill4carson wrote:
>> On 2012?05?30? 14:38, Will Deacon wrote:
>>> On Tue, May 29, 2012 at 06:28:11AM +0100, bill4carson wrote:
>>>> --- a/arch/arm/mm/cache-v6.S
>>>> +++ b/arch/arm/mm/cache-v6.S
>>>> @@ -170,6 +170,10 @@ ENDPROC(v6_coherent_kern_range)
>>>>     ENTRY(v6_flush_kern_dcache_area)
>>>>            add     r1, r0, r1
>>>>     1:
>>>> +#ifdef CONFIG_SMP
>>>> +       ldr     r2, [r0]                        @ read for ownership
>>>> +       str     r2, [r0]                        @ write for ownership
>>>> +#endif /* CONFIG_SMP */
>>>>     #ifdef HARVARD_CACHE
>>>>            mcr     p15, 0, r0, c7, c14, 1          @ clean&   invalidate D line
>>>>     #else
>>>
>>> I don't think the invalidation is needed here, so you probably don't need to
>>> hack this function at all.
> ...
>> 1. task t runs on CPU 0, it executes one program in nand flash,
>>      so first task t read *part* of this program into its local Dcache,
>>      let's call it part_a;
>>
>> 2. task t migrates from CPU0 onto CPU1, in there reads the rest of
>>      program into its local Dcache, label it part_b;
>>
>> 3. on CPU1, task t flush the whole address range of this program,
>>      As with ARM11 MPCore, this flush is locally effective, after flush
>>      part_a still resides in CPU0 L1 Dcache.
>>
>> 4. When this program gets executed, CPU 1 fetch its instructions from
>>      Icache, SCU will notice this action,
>>
>>      Question:
>>      At this point, is stale part_a in main memory *or* L1 Dcache part_a
>>      in CPU0 routed into CPU1 as instruction?
>
> This has been discussed in the past. The first thing is to disable
> CONFIG_PREEMPT to make sure you are not preempted between page copying
> and task execution. The code doing the page copy needs to call
> flush_dcache_page() on the CPU where the copy occurred and Linux does a
> non-lazy D-cache flush. But there are many situations where Linux
> doesn't do this (you can google for flush_dcache_page and my name to
> find a few places where I tried to fix this).
>
Thanks:)


> AFAIK, The SCU only snoops the D-cache, not the I-cache. We have a full
> I-cache invalidation during task migration.

                             ^^^^^^^^^^^^
Could you please point it to me?




-- 
Love each day!

--bill

  reply	other threads:[~2012-05-31  3:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09  9:11 Query about: ARM11 MPCore: preemption/task migration cache coherency bill4carson
2012-05-11  8:51 ` Will Deacon
2012-05-11  9:53   ` bill4carson
2012-05-29  5:28   ` bill4carson
2012-05-30  6:38     ` Will Deacon
2012-05-30 10:01       ` bill4carson
2012-05-31  3:00         ` Catalin Marinas
2012-05-31  3:11           ` bill4carson [this message]
2012-05-31  3:12             ` Catalin Marinas
2012-05-31  3:19             ` Catalin Marinas
2012-05-31  3:38               ` bill4carson
2012-05-31  3:58                 ` Catalin Marinas
2012-05-31  5:06                   ` bill4carson
2012-05-31  5:19                     ` Catalin Marinas
2012-05-31  5:51                       ` bill4carson
2012-05-31  6:56                         ` Catalin Marinas
2012-05-31  7:21                           ` bill4carson
2012-05-31  7:46                             ` snakky.zhang at gmail.com
2012-05-31 16:04                               ` Catalin Marinas
2012-06-01  1:11                                 ` snakky.zhang at gmail.com
2012-06-01  3:25                                   ` Catalin Marinas
2012-06-01  5:21                                     ` snakky.zhang at gmail.com
2012-06-01  1:34                                 ` snakky.zhang at gmail.com
2012-06-01  3:29                                   ` Catalin Marinas
2012-06-03 11:34                                     ` Russell King - ARM Linux
2012-06-04  9:20                                       ` snakky.zhang at gmail.com
2012-06-05  4:06 ` George G. Davis
2012-06-05  4:50   ` bill4carson
2012-06-06  6:18     ` Andrew Yan-Pai Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FC6E172.4080601@gmail.com \
    --to=bill4carson@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).