linux-mips
[Top] [All Lists]

Re: data consistency of high page

To: NamJae Jeon <linkinjeon@gmail.com>
Subject: Re: data consistency of high page
From: "Dennis.Yxun" <dennis.yxun@gmail.com>
Date: Tue, 28 Feb 2012 11:03:02 +0800
Cc: Minchan Kim <minchan.kim@gmail.com>, Ralf Baechle <ralf@linux-mips.org>, lkml <linux-kernel@vger.kernel.org>, linux-mips <linux-mips@linux-mips.org>, yan@mips.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uRGxvOeQhK9Q9dDkJO58lrpWHx+c0JyUYLCVs6WTMvg=; b=uzuMwhIN9ogs94PD34ZtxKshm2NVksdBgW6FANbbJN6koR+jscLQx93wnRcGluya+C HEFc8A33jsdQadAZhjTxASTOgp9VYvcFZ7PacIr9RrFDMUuzpo74AhVjWbe/WmO33Gy0 a83FxNFcaq+W9kwQsbi5veniWy6lifIhIyn7A=
In-reply-to: <BANLkTimKw3mg8N-gBxh3jbo9msaHOF3qPA@mail.gmail.com>
References: <28c262361003230146o7bca61e6h3af2062b1172fdb2@mail.gmail.com> <afc622a1003230511o108556f4s5d1282bd3122b3d9@mail.gmail.com> <BANLkTimKw3mg8N-gBxh3jbo9msaHOF3qPA@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
Hi NamJae:
 We hit pretty much the same problem, highmem + cache consistence
but our hardware should have cache alias problem
 Could you try attached following patch?

dmesg:
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)             
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) 
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)   
[    0.000000] Primary instruction cache 16kB, VIPT, 4-way, linesize 32 bytes. 
[    0.000000] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 32 byt
es                                                                             
[    0.000000] MIPS secondary cache 128kB, 8-way, linesize 32 bytes.           
[    0.000000] Writing ErrCtl register=00000000                                
[    0.000000] Readback ErrCtl register=00000000                               
[    0.000000] Memory: 510548k/262144k available (2728k kernel code, 13740k rese
rved, 630k data, 5784k init, 262144k highmem)

diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 00d70c8..536b7f9 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -15,6 +15,7 @@
 #include <linux/sched.h>
 #include <linux/syscalls.h>
 #include <linux/mm.h>
+#include <linux/highmem.h>
 
 #include <asm/cacheflush.h>
 #include <asm/processor.h>
@@ -83,8 +84,13 @@ void __flush_dcache_page(struct page *page)
        struct address_space *mapping = page_mapping(page);
        unsigned long addr;
 
-       if (PageHighMem(page))
+       if (PageHighMem(page) &&
+               (addr = (unsigned long) kmap_atomic(page, KM_SYNC_DCACHE))) {
+               flush_data_cache_page(addr);
+               kunmap_atomic((void *)addr, KM_SYNC_DCACHE);
                return;
+       }


On Tue, Apr 5, 2011 at 4:17 PM, NamJae Jeon <linkinjeon@gmail.com> wrote:
Hi.

As you know, there is cache operation about highpage in arm arch.

arch/arm/mm/flush.c
-----------------------------------------------------------------------------------------------
if (!PageHighMem(page)) {
               __cpuc_flush_dcache_area(page_address(page), PAGE_SIZE);
       } else {
               void *addr = kmap_high_get(page);
               if (addr) {
                       __cpuc_flush_dcache_area(addr, PAGE_SIZE);
                       kunmap_high(page);
               } else if (cache_is_vipt()) {
                       /* unmapped pages might still be cached */
                       addr = kmap_atomic(page);
                       __cpuc_flush_dcache_area(addr, PAGE_SIZE);
                       kunmap_atomic(addr);
               }
       }
-------------------------------------------------------------------------------------------------

currently, mips kernel just return without cache operation.

Would you plz tell me your opinion ?

Thanks.


2010/3/23 NamJae Jeon <linkinjeon@gmail.com>:
> Hi. Ralf.
>
> I'm Namjae.jeon. nice to meet you.
>
> I face cache aliasing problem on mips 34ke.
>
> Our target cache is 34kB 4way i/d-cache , 32bytes linesize.
>
> As you know, there is possibility of cache aliasing on 8kB per way.
>
> But mips arch of kernel mainline can not properly  handile this case.
>
> For example, highmem handling in __fluash_dcache_page function is just return.
>
> So, if argument page is page in highmem, it can not flush in dcache line.
>
> I want to listen your opinion.
>
> Thanks.
>
>
> 2010/3/23 Minchan Kim <minchan.kim@gmail.com>:
>> Hi, Ralf.
>>
>> Below is thread long time ago.
>> At that time, we can't end up the problem by some reason.
>> Sorry for that.
>>
>> The problem would occur, again.
>>
>> On Fri, Oct 16, 2009 at 6:24 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
>>> On Fri, Oct 16, 2009 at 02:17:19PM +0900, Minchan Kim wrote:
>>>
>>>> Many code of kernel fs usually allocate high page and flush.
>>>> But flush_dcache_page of mips checks PageHighMem to avoid flush
>>>> so that data consistency is broken, I think.
>>>
>>> What processor and cache configuration?
>>>
>>>> I found it's by you and Atsushi-san on 585fa724.
>>>> Why do we need the check?
>>>> Could you elaborte please?
>>>
>>> The if statement exists because __flush_dcache_page would crash if a page
>>> is not mapped.  This of course isn't correct but that wasn't a problem
>>> since highmem still is only supported on machines that don't have aliases.
>>>
>>>  Ralf
>>>
>>
>> Our system is following as.
>>
>> mips 34ke
>> primary i-cache 32kB VIPT 4way 32 byte line size.
>> primary d-cache 32kB 4way  32 bytes linesize
>>
>> If you have further questions, Namjae, Could you follow question of Ralf?
>>
>> --
>> Kind regards,
>> Minchan Kim
>>
>


<Prev in Thread] Current Thread [Next in Thread>