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
next prev parent 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).