Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 16 Aug 2003 12:09:50 +0200 | From | Manfred Spraul <> | Subject | Re: [BUG] slab debug vs. L1 alignement |
| |
Benjamin Herrenschmidt wrote:
>>>Yes, I understand that, but that is wrong for GFP_DMA imho. Also, >>>SLAB_MUST_HWCACHE_ALIGN just disables redzoning, which is not smart, >>>I'd rather allocate more and keep both redzoning and cache alignement, >>>that would help catch some of those subtle problems when a chip DMA >>>engine plays funny tricks. >>> >>> >>> >>I don't want to upgrade SLAB_HWCACHE_ALIGN to SLAB_MUST_HWCACHE_ALIGN >>depending on GFP_DMA: IIRC one arch (ppc64?) marks everything as >>GFP_DMA, because all memory is DMA capable. >> >> > >Same for ppc32. Anyway, I don't like MUST_HWCACHE_ALIGN because it >just disables redzoning, I'd rather allocate more and do both redzoning >and cache alignement. > > I have a patch that creates helper functions that make that simple. The patch is stuck right now, because it exposes a bug in the i386 debug register handling. I'll add it redzoning with MUST_HWCACHE_ALIGN after that one is in.
>Anyway, I _still_ think it's stupid to return non-aligned buffers, both >for performances, and because that prevents from dealing with such cases, >typically the SCSI layer assumes alignement here among others... > > I don't care about performance with slab debugging on. kmalloc(4096,) usually takes ~40 cpu ticks on i386. With debugging on, it includes a memset and an open coded memcmp - my guess is a few thousand cpu ticks, and that's intentional. Do not enable it on production systems.
>Regarding O_DIRECT with an unaligned pointer, I haven't looked at this >case yet, I suppose it will be broken in a whole lot of cases. > > Hmm. That means slab debugging did it's job: The driver contains the wrong assumption that all pointers are cache line aligned. Without slab debugging, this would result in rare data corruptions in O_DIRECT apps. With slab debugging on, it's exposed immediately.
-- Manfred
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |