USB mass storage and ARM cache coherency
in [Kernel]
|
Prev: [PATCH 0/3] HID: make raw output callback more flexible
Next: kprobes: Disable booster when CONFIG_PREEMPT=y
From: Russell King - ARM Linux on 26 Feb 2010 16:10 On Fri, Feb 26, 2010 at 04:25:21PM +0000, Catalin Marinas wrote: > For mmap'ed pages (and present in the page cache), is it guaranteed that > the HCD driver won't write to it once it has been mapped into user > space? If that's the case, it may solve the problem by just reversing > the meaning of PG_arch_1 on ARM and assume that a newly allocated page > has dirty D-cache by default. I guess we could also set PG_arch_1 in the DMA API as well, to avoid the unnecessary D cache flushing when clean pages get mapped into userspace. -- 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 26 Feb 2010 16:50 On Fri, 2010-02-26 at 16:25 +0000, Catalin Marinas wrote: > > For mmap'ed pages (and present in the page cache), is it guaranteed that > the HCD driver won't write to it once it has been mapped into user > space? If that's the case, it may solve the problem by just reversing > the meaning of PG_arch_1 on ARM and assume that a newly allocated page > has dirty D-cache by default. Well, I don't see why the HCD would write to it unless it's swapped out, and thus unmapped or read() to or similar. > The filesystem layer does it only if it needs to touch the data written > by the block device (e.g. cramfs, jffs). Some block devices call > flush_dcache_page (like mmci.c) while some others don't (and those that > use DMA actually don't since the DMA API handles the flushing). Hrm, the DMA API certainly doesn't handle the I$/D$ coherency on powerpc.. I'm afraid that whole cache handling stuff is totally inconsistent since different archs have different expectations here. Maybe we need to revisit things in that area, though it might require to be done properly to have not one but two bits in struct page to separately track the D$ and I$ state ... 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: Russell King - ARM Linux on 26 Feb 2010 17:00 On Sat, Feb 27, 2010 at 08:40:29AM +1100, Benjamin Herrenschmidt wrote: > Hrm, the DMA API certainly doesn't handle the I$/D$ coherency on > powerpc.. I'm afraid that whole cache handling stuff is totally > inconsistent since different archs have different expectations here. It doesn't on ARM either. -- 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 26 Feb 2010 17:00 On Fri, 2010-02-26 at 11:52 -0500, Alan Stern wrote: > > For mmap'ed pages (and present in the page cache), is it guaranteed that > > the HCD driver won't write to it once it has been mapped into user > > space? If that's the case, it may solve the problem by just reversing > > the meaning of PG_arch_1 on ARM and assume that a newly allocated page > > has dirty D-cache by default. > > Nothing is guaranteed. The HCD will write to wherever it is asked. If > a driver does input to an mmap'ed page, the HCD won't even know that > the page is mmap'ed. Right but that won't happen unless somebody explicitely caused that input to happen, typically, a userspace read(). I$/D$ coherency isn't implicit in that case. The question is more when the kernel itself moves a page in/out from underneath the application (mmap'ed executable pages). One it's mapped in, it won't be written to by the HCD unless something explicitely does something to cause that write. If it's swapped out and back in, it will have been unmapped. 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: Russell King - ARM Linux on 26 Feb 2010 17:10
On Sat, Feb 27, 2010 at 08:49:40AM +1100, Benjamin Herrenschmidt wrote: > It will deadlock if you use normal IRQs. I don't see a good way around > that other than using a higher-level type of IRQs. I though ARM has > something like that (FIQs ?). Can you use those guys for IPIs ? If the hardware did support using FIQs for IPIs, this would not be desirable because then it takes it away from the SoC folk to do what they will with it. In the past, it's been used as a fast CPU-driven "DMA" interface - some SoCs have been wired up in such a way that's the only use available for the FIQ. The other problem we'd encounter using FIQs for IPIs is that some IPIs need to take locks - and in order to make that safe, we'd either need another class of locks which disable IRQs and FIQs together, or we'd need to disable FIQs everywhere we disable IRQs - at which point FIQs become utterly pointless. (There only differences between FIQ and IRQ are: - on simultaneous raising of both, the FIQ will be called before the IRQ. - each has its own (single) vector. - invocation of FIQ masks IRQ. What I'm saying is that what gives FIQ an advantage for SoC people is that it's bare bones light weight and therefore extremely fast - as soon as you load it up with additional complexity, it becomes less useful.) -- 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/ |