linux-kernel - Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BF0DE5E.4010904@petalogix.com>
Date:	Mon, 17 May 2010 08:12:46 +0200
From:	Michal Simek <michal.simek@...alogix.com>
To:	Mike Frysinger <vapier.adi@...il.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Johannes Weiner <jw@...ix.com>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Matt Mackall <mpm@...enic.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oskar Schirmer <os@...ix.com>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Daniel Glöckner <dg@...ix.com>,
	Oliver Schneidewind <osw@...ix.com>,
	Nick Piggin <npiggin@...e.de>,
	David Rientjes <rientjes@...gle.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines

Mike Frysinger wrote:
> On Tue, May 11, 2010 at 17:53, Dmitry Torokhov wrote:
>> On Tue, May 11, 2010 at 11:48:36PM +0200, Johannes Weiner wrote:
>>> On Tue, May 11, 2010 at 04:54:41PM -0400, Mike Frysinger wrote:
>>>> does the phrase "DMA safe buffer" imply cache alignment ?
>>> I guess that depends on the architectural requirements.  On x86,
>>> apparently, not so much.  On ARM, probably yes, as it's the
>>> requirement to properly maintain coherency.
>> It looks liek ARM (and a few others) do this:
>>
>> [dtor@...mer work]$ grep -r ARCH_KMALLOC_MINALIGN arch/
>> arch/sh/include/asm/page.h:#define ARCH_KMALLOC_MINALIGN        L1_CACHE_BYTES
>> arch/frv/include/asm/mem-layout.h:#define       ARCH_KMALLOC_MINALIGN           8
>> arch/powerpc/include/asm/page_32.h:#define ARCH_KMALLOC_MINALIGN        L1_CACHE_BYTES
>> arch/arm/include/asm/cache.h:#define ARCH_KMALLOC_MINALIGN      L1_CACHE_BYTES
>> arch/microblaze/include/asm/page.h:#define ARCH_KMALLOC_MINALIGN        L1_CACHE_BYTES
>> arch/mips/include/asm/mach-tx49xx/kmalloc.h: * All happy, no need to define ARCH_KMALLOC_MINALIGN
>> arch/mips/include/asm/mach-ip27/kmalloc.h: * All happy, no need to define ARCH_KMALLOC_MINALIGN
>> arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_KMALLOC_MINALIGN 32
>> arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_KMALLOC_MINALIGN 128
>> arch/mips/include/asm/mach-generic/kmalloc.h:#define ARCH_KMALLOC_MINALIGN      128
>> arch/avr32/include/asm/cache.h:#define ARCH_KMALLOC_MINALIGN    L1_CACHE_BYTES
> 
> if ARCH_KMALLOC_MINALIGN is not defined, the current allocators default to:
>  slub - alignof(unsigned long long)
>  slab - alignof(unsigned long long)
>  slob - alignof(unsigned long)
> which for many arches can mean an alignment of merely 4 or 8
> 
> lets look at the cacheline sizes for arches that dont set
> ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES:
>  - alplha - 32 or 64
>  - frv - 32 or 64
>  - blackfin - 32
>  - parisc - 32 or 64
>  - mn10300 - 16
>  - s390 - 256
>  - score - 16
>  - sparc - 32
>  - xtensa - 16 or 32

Just for completion.

microblaze - 16 or 32.

Michal

-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/