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: Wed, 30 May 2012 18:01:59 +0800	[thread overview]
Message-ID: <4FC5F017.4050202@gmail.com> (raw)
In-Reply-To: <20120530063858.GB6484@mudshark.cambridge.arm.com>

Hi, Will

First of all, Thanks your attentions for this issue.


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.


     CPU0                        CPU1
+--------------------+        +--------------------+   +----------+
| L1 Dcache   part_a |        | L1 Dcache   part_b |   |  Icache  |
+--------------------+        +--------------------+   +----------+
             ^                                            |
             |                   +------------------------+
             |                   |
             |         SCU       V
     +-------|-------------------|---------+
     |       +------- ??? -------+         |
     |                 |                   |
     +-----------------|-------------------+
                       |
                       V
              Main   Memory
     +-------------------------------------+
     |       stale part_a       part_b     |
     +-------------------------------------+


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?



>
>> But I have no idea on how to accomplish the v6_flush_kern_cache_all,
>> maybe IPI is needed?
>
> We could add an IPI to invalidate the I-caches on the other cores, however
> I haven't checked to see if we could instead do something on the CPU
> migration path which avoid the need for the broadcasting.
>


Another workaround is mark the task migrations in function "pull_task",
while in function "context_switch", check it to see if any tasks
migrated into current CPU, if there do be such tasks, flush entire data
cache on remote core(the source core of task migration) and wait the
operation accomplished. This is also verified. But from my point of
view, this is just a temporary workaround instead of resolution.
The little patch above should be the right one that fix this bug:
Make the flush_kern_dcache_area global affective.


It's very pleased if you could give your insights in this.


> Will
>

-- 
Love each day!

--bill

  reply	other threads:[~2012-05-30 10:01 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 [this message]
2012-05-31  3:00         ` Catalin Marinas
2012-05-31  3:11           ` bill4carson
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=4FC5F017.4050202@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).