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:38:54 +0800 [thread overview]
Message-ID: <4FC6E7CE.9090004@gmail.com> (raw)
In-Reply-To: <20120531031941.GA29906@mbp>
On 2012?05?31? 11:19, Catalin Marinas wrote:
> On Thu, May 31, 2012 at 04:11:46AM +0100, bill4carson wrote:
>> On 2012?05?31? 11:00, Catalin Marinas wrote:
>>> 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:)
>
> BTW, see this as a starting point (and a hack):
>
> http://article.gmane.org/gmane.linux.ports.arm.kernel/51556
I think we has some mis-understanding here :(
As for:v6_flush_kern_dcache_area/v6_flush_kern_dcache_all
these two hooks is supposed to be globally effective, *not*
locally!
Hence, there should below fix to make it as globally effective.
+#ifdef CONFIG_SMP
+ ldr r2, [r0] @ read for ownership
+ str r2, [r0] @ write for ownership
+#endif /* CONFIG_SMP */
Or there maybe some other better solution for this issue.
thanks
--
Love each day!
--bill
next prev parent reply other threads:[~2012-05-31 3:38 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
2012-05-31 3:12 ` Catalin Marinas
2012-05-31 3:19 ` Catalin Marinas
2012-05-31 3:38 ` bill4carson [this message]
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=4FC6E7CE.9090004@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).