Re: data consistency of high page

[Namjae Jeon]

2012/2/28 Dennis.Yxun <dennis.yxun@xxxxxxxxx>:
> 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?
Hi Dennis.
I already fixed it as your patch in our system before.
your patch looks reasonable to me.
Would you post this patch with adding the below ?

Reviewed-by: Namjae Jeon <linkinjeon@xxxxxxxxx>
Tested-by: Namjae Jeon <linkinjeon@xxxxxxxxx>

Thanks~

>
> 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@xxxxxxxxx> 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@xxxxxxxxx>:
>> > 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@xxxxxxxxx>:
>> >> 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@xxxxxxxxxxxxxx>
>> >> 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
>> >>
>> >
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/