public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Cc: Kai Makisara <Kai.Makisara@kolumbus.fi>,
	Manfred Spraul <manfred@colorfullife.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [BUG] slab debug vs. L1 alignement
Date: 17 Aug 2003 12:27:41 -0500	[thread overview]
Message-ID: <1061141263.2139.33.camel@fuzzy> (raw)

Perhaps we should remind ourselves what the alignment rules actually are
for kmalloc:

1) No two kmalloc allocations may share cache lines (otherwise data
corruption will result).
2) kmalloc should be on a power of two alignment consistent with the
widest processor data access requirements.

Now note that 1) is optional (but an efficiency speed up) for a coherent
architecture.  It is an *absolute requirement* for a non-coherent
architecture.

2) is essentially what's causing Ben the problems.  His driver appears
to be insisting that DMA be a full PCI cache line width.  I can see
arguments for making this a driver problem.

However, as far as the redzoning issue goes, I think in order to avoid
cache line interference, the redzone should be sized to be a cache line
width, at least on non-coherent architectures.

In theory, the above should solve everyone's problems.

As far as I/O from user land goes (especially to tape), the users
usually can work out the alignment constraints and act accordingly.  I'm
agnostic as to whether we should fail (with an error indicating
alignment problems) or rebuffer causing inefficiency in throughput in
the misaligned case.

James




             reply	other threads:[~2003-08-17 17:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-17 17:27 James Bottomley [this message]
2003-08-18 20:29 ` [BUG] slab debug vs. L1 alignement Kai Makisara
2003-09-30 18:40 ` Manfred Spraul
     [not found] <kUMe.2pd.9@gated-at.bofh.it>
     [not found] ` <kWuz.41M.5@gated-at.bofh.it>
     [not found]   ` <kYwo.5Xr.1@gated-at.bofh.it>
     [not found]     ` <l5HD.4tl.21@gated-at.bofh.it>
     [not found]       ` <l6kd.53T.1@gated-at.bofh.it>
2003-08-16 12:00         ` Arnd Bergmann
2003-08-16 12:18           ` Manfred Spraul
  -- strict thread matches above, loose matches on Subject: below --
2003-08-15 21:50 Manfred Spraul
2003-08-15 23:41 ` Benjamin Herrenschmidt
2003-08-16  1:47   ` Manfred Spraul
2003-08-16  9:37     ` Benjamin Herrenschmidt
2003-08-16 10:09       ` Manfred Spraul
2003-08-16 10:43         ` Benjamin Herrenschmidt
2003-08-16 11:21           ` Kai Makisara
2003-08-16 11:36             ` Benjamin Herrenschmidt
2003-08-16 14:39               ` Kai Makisara
2003-08-15 14:00 Benjamin Herrenschmidt
2003-08-15 18:51 ` Philippe Elie
2003-08-15 16:54   ` Benjamin Herrenschmidt
2003-08-15 21:16 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1061141263.2139.33.camel@fuzzy \
    --to=james.bottomley@steeleye.com \
    --cc=Kai.Makisara@kolumbus.fi \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox