ARM: Assume new page cache pages have dirty D-cache
in [Kernel]
|
Prev: [tip:perf/pebs] perf trace: Don't use pager if scripting
Next: arch/powerpc/sysdev/cpm2_pic.h: Checkpatch cleanup
From: Benjamin Herrenschmidt on 4 Mar 2010 23:40 > As I just realised, this is going to subject all pages placed into > userspace with a D cache flush - even anonymous pages, and those > which we've been careful to deal with the cache issues already (eg, > via the COW page copying code.) > > I think all the copypage functions need to set PG_dcache_clean on the > new pages once their copy has completed. > > I wonder if there's any other anonymous page creating functions which > could do with a similar treatment... Do we do anything other than COW and zero page ? clear_user_page() I suppose could deal with that if you do the cache bits there. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 4 Mar 2010 23:50 On Fri, 2010-03-05 at 10:28 +0900, Paul Mundt wrote: > In the anonymous page case, flush_anon_page() is always called prior to > flush_dcache_page(), so flush_anon_page() could just set PG_dcache_clean > to work around that. That would handle get_user_pages(), too. Well, currently, we clear PG_arch_1 in flush_dcache_page(), at least on ppc. Now, I have a nagging feeling that we might not need to... I'll have to give it a closer look when I'm back from this extended week-end :-) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on 5 Mar 2010 12:00 On Thu, 2010-03-04 at 21:44 +0000, Russell King - ARM Linux wrote: > On Thu, Mar 04, 2010 at 06:36:42PM +0000, Catalin Marinas wrote: > > ARM: Assume new page cache pages have dirty D-cache > > > > From: Catalin Marinas <catalin.marinas(a)arm.com> > > > > There are places in Linux where writes to newly allocated page cache > > pages happen without a subsequent call to flush_dcache_page() (several > > PIO drivers including USB HCD). This patch changes the meaning of > > PG_arch_1 to be PG_dcache_clean and always flush the D-cache for a newly > > mapped page in update_mmu_cache(). > > > > The patch also sets the PG_arch_1 bit in the DMA cache maintenance > > function to avoid additional cache flushing in update_mmu_cache(). > > As I just realised, this is going to subject all pages placed into > userspace with a D cache flush - even anonymous pages, and those > which we've been careful to deal with the cache issues already (eg, > via the COW page copying code.) > > I think all the copypage functions need to set PG_dcache_clean on the > new pages once their copy has completed. As Ben said, I think we can set PG_dcache_clean in the clear/copy_user_page() functions. My doubt with these functions is the highmem cases where kunmap_atomic() only flushes the D-cache in one situation, the other just calling kunmap_high() which doesn't seem to do anything to the caches. But for non-aliasing VIPT, do we actually need the D-cache flushing in kunmap_atomic() or copy_user_page()? If we default to new page being dirty, I think we can remove the cache cleaning from this function and leave it for update_mmu_cache (or set_pte_at but that's for a different patch). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 5 Mar 2010 16:20 On Fri, Mar 05, 2010 at 04:52:40PM +0000, Catalin Marinas wrote: > As Ben said, I think we can set PG_dcache_clean in the > clear/copy_user_page() functions. My doubt with these functions is the > highmem cases where kunmap_atomic() only flushes the D-cache in one > situation, the other just calling kunmap_high() which doesn't seem to do > anything to the caches. In which case you're totally missing the point with these functions. The copy_user_page and clear_user_page functions specifically do tricks to ensure that they can avoid additional cache maintainence - or any cache maintainence at all. For instance, on aliasing VIPT, they will map the user page in using the same colour as the ultimate userspace address, ensuring that any cache lines created will be visible to the userspace application. So what kunmap_atomic() does with caches is not really relevant to the coherency issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on 6 Mar 2010 05:10
On Fri, 2010-03-05 at 21:16 +0000, Russell King - ARM Linux wrote: > On Fri, Mar 05, 2010 at 04:52:40PM +0000, Catalin Marinas wrote: > > As Ben said, I think we can set PG_dcache_clean in the > > clear/copy_user_page() functions. My doubt with these functions is the > > highmem cases where kunmap_atomic() only flushes the D-cache in one > > situation, the other just calling kunmap_high() which doesn't seem to do > > anything to the caches. > > In which case you're totally missing the point with these functions. > The copy_user_page and clear_user_page functions specifically do tricks > to ensure that they can avoid additional cache maintainence - or any > cache maintainence at all. > > For instance, on aliasing VIPT, they will map the user page in using > the same colour as the ultimate userspace address, ensuring that any > cache lines created will be visible to the userspace application. I was more thinking for the non-aliasing VIPT case where we could defer the flushing until update_mmu_cache(). But I'm fine with just setting PG_dcache_clean in these functions to avoid checks on non-aliasing vs. aliasing VIPT. > So what kunmap_atomic() does with caches is not really relevant to the > coherency issue. The relevant part is that if highmem is enabled, copy_user_page() does not flush the D-cache, leaving it to kunmap_atomic(). Does this latter function flush the D-cache in all the relevant situations? -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |