ad7877: keep dma rx buffers in seperate cache lines
in [Kernel]
|
Prev: cpuset,mm: fix no node to alloc memory when changing cpuset's mems
Next: tracing: Fix function declarations if !CONFIG_STACKTRACE
From: David Woodhouse on 19 May 2010 08:50 On Wed, 2010-05-12 at 13:03 +1000, Nick Piggin wrote: > I don't think it's necessarily a good idea. MINALIGN is an enforced > minimum alignment and the allocator has no leeway in reducing this. > In a UP system, or in a memory constrained system, it might be a better > idea to pack objects more tightly, for example. > > If we allow drivers to assume kmalloc is cacheline aligned, it will be > (practically) impossible to revert this because it would require driver > audits. No, we definitely don't, and shouldn't, allow drivers to assume that kmalloc is cacheline-aligned. However, we _do_ allow drivers to assume that kmalloc is DMA-safe. That happens to mean "cacheline-aligned" for cache-incoherent architectures, but drivers should never really have to think about that. > So whenever strengthening API guarantees like this, it is better to be > very careful and conservative. Probably even introducing a new API with > the stronger semantics (even if it is just a wrapper in the case where > KMALLOC_MINALIGNED *is* cacheline sized). We're not talking about strengthening API guarantees. It's _always_ been this way; it's just that some architectures are buggy. But it looks like ARM, PowerPC, SH, MIPS, Microblaze, AVR32 and all unconditionally cache-coherent architectures _do_ get it right already. > I think adding to the DMA API would be a better idea. If the arch knows > that kmalloc is suitable for the job directly, it can be used. Drivers > can use the new interface, and kmalloc doesn't get saddled with > alignment requirements. No, that would be a change which would require auditing all drivers. The _current_ rule is that buffers returned from kmalloc() are OK for DMA. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- 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: Nick Piggin on 19 May 2010 09:10 On Wed, May 19, 2010 at 01:48:45PM +0100, David Woodhouse wrote: > On Wed, 2010-05-12 at 13:03 +1000, Nick Piggin wrote: > > I don't think it's necessarily a good idea. MINALIGN is an enforced > > minimum alignment and the allocator has no leeway in reducing this. > > In a UP system, or in a memory constrained system, it might be a better > > idea to pack objects more tightly, for example. > > > > If we allow drivers to assume kmalloc is cacheline aligned, it will be > > (practically) impossible to revert this because it would require driver > > audits. > > No, we definitely don't, and shouldn't, allow drivers to assume that > kmalloc is cacheline-aligned. Good. > However, we _do_ allow drivers to assume that kmalloc is DMA-safe. That > happens to mean "cacheline-aligned" for cache-incoherent architectures, > but drivers should never really have to think about that. DMA-safe for GFP_DMA, or all kmalloc? Either way, yes the arch should take care of those details. > > So whenever strengthening API guarantees like this, it is better to be > > very careful and conservative. Probably even introducing a new API with > > the stronger semantics (even if it is just a wrapper in the case where > > KMALLOC_MINALIGNED *is* cacheline sized). > > We're not talking about strengthening API guarantees. It's _always_ been > this way; it's just that some architectures are buggy. It just appeared, in the post I replied to, that there was a suggestion of making it explicitly cacheline aligned. If I misread that, ignore me. > > But it looks like ARM, PowerPC, SH, MIPS, Microblaze, AVR32 and all > unconditionally cache-coherent architectures _do_ get it right already. > > > I think adding to the DMA API would be a better idea. If the arch knows > > that kmalloc is suitable for the job directly, it can be used. Drivers > > can use the new interface, and kmalloc doesn't get saddled with > > alignment requirements. > > No, that would be a change which would require auditing all drivers. The > _current_ rule is that buffers returned from kmalloc() are OK for DMA. > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse(a)intel.com Intel Corporation -- 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: David Woodhouse on 19 May 2010 09:20 On Wed, 2010-05-19 at 23:07 +1000, Nick Piggin wrote: > On Wed, May 19, 2010 at 01:48:45PM +0100, David Woodhouse wrote: > > However, we _do_ allow drivers to assume that kmalloc is DMA-safe. That > > happens to mean "cacheline-aligned" for cache-incoherent architectures, > > but drivers should never really have to think about that. > > DMA-safe for GFP_DMA, or all kmalloc? Try not to think about that. Seriously, look over there! A kitten! (You have to use the DMA API anyway, so swiotlb will handle things if you're trying to use pages which are above the range that certain devices can reach. But we're only talking about the problems of sharing cache lines here; don't worry about that bit.) > > > So whenever strengthening API guarantees like this, it is better to be > > > very careful and conservative. Probably even introducing a new API with > > > the stronger semantics (even if it is just a wrapper in the case where > > > KMALLOC_MINALIGNED *is* cacheline sized). > > > > We're not talking about strengthening API guarantees. It's _always_ been > > this way; it's just that some architectures are buggy. > > It just appeared, in the post I replied to, that there was a suggestion > of making it explicitly cacheline aligned. If I misread that, ignore > me. Actually I think you read it just fine -- but it was misguided. They meant to say "cacheline aligned on architectures with cache-incoherent DMA which need that". But that's what ARCH_KMALLOC_MINALIGN is _already_ supposed to do. If any architecture needs to set ARCH_KMALLOC_MINALIGN but doesn't, that's broken. The 'cacheline aligned' misconception did manage to get into the ad7877 driver in commit 3843384a though -- it now uses ____cacheline_aligned instead of __attribute__((__aligned__(ARCH_KMALLOC_MINALIGN))) as it should. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- 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: Nick Piggin on 19 May 2010 09:40 On Wed, May 19, 2010 at 02:17:47PM +0100, David Woodhouse wrote: > On Wed, 2010-05-19 at 23:07 +1000, Nick Piggin wrote: > > On Wed, May 19, 2010 at 01:48:45PM +0100, David Woodhouse wrote: > > > However, we _do_ allow drivers to assume that kmalloc is DMA-safe. That > > > happens to mean "cacheline-aligned" for cache-incoherent architectures, > > > but drivers should never really have to think about that. > > > > DMA-safe for GFP_DMA, or all kmalloc? > > Try not to think about that. Seriously, look over there! A kitten! > > (You have to use the DMA API anyway, so swiotlb will handle things if > you're trying to use pages which are above the range that certain > devices can reach. But we're only talking about the problems of sharing > cache lines here; don't worry about that bit.) Yeah, well, GFP_DMA is pretty crappy anyway. I was just curious, but it's no big deal to support dma with regular kmalloc. > > > > So whenever strengthening API guarantees like this, it is better to be > > > > very careful and conservative. Probably even introducing a new API with > > > > the stronger semantics (even if it is just a wrapper in the case where > > > > KMALLOC_MINALIGNED *is* cacheline sized). > > > > > > We're not talking about strengthening API guarantees. It's _always_ been > > > this way; it's just that some architectures are buggy. > > > > It just appeared, in the post I replied to, that there was a suggestion > > of making it explicitly cacheline aligned. If I misread that, ignore > > me. > > Actually I think you read it just fine -- but it was misguided. They > meant to say "cacheline aligned on architectures with cache-incoherent > DMA which need that". But that's what ARCH_KMALLOC_MINALIGN is _already_ > supposed to do. If any architecture needs to set ARCH_KMALLOC_MINALIGN > but doesn't, that's broken. > > The 'cacheline aligned' misconception did manage to get into the ad7877 > driver in commit 3843384a though -- it now uses ____cacheline_aligned > instead of __attribute__((__aligned__(ARCH_KMALLOC_MINALIGN))) as it > should. OK so long as there is not a "must be cacheline aligned" requirement. Your proposal for a __dma_aligned attribute in an arch header looks like a good idea there. -- 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: Johannes Weiner on 19 May 2010 09:50
On Wed, May 19, 2010 at 11:36:56PM +1000, Nick Piggin wrote: > On Wed, May 19, 2010 at 02:17:47PM +0100, David Woodhouse wrote: > > > > The 'cacheline aligned' misconception did manage to get into the ad7877 > > driver in commit 3843384a though -- it now uses ____cacheline_aligned > > instead of __attribute__((__aligned__(ARCH_KMALLOC_MINALIGN))) as it > > should. > > OK so long as there is not a "must be cacheline aligned" requirement. > Your proposal for a __dma_aligned attribute in an arch header looks > like a good idea there. Would you happen to know of other potential users? At this point I'd much rather just allocate the buffers dynamically and hide the issue nicely behind kmalloc(). -- 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/ |