public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: [BUG] slab debug vs. L1 alignement
Date: 15 Aug 2003 16:00:04 +0200	[thread overview]
Message-ID: <1060956004.581.13.camel@gaston> (raw)

Currently, when enabling slab debugging, we lose the property of
having the objects aligned on a cache line size.

This is, imho, an error, especially if GFP_DMA is passed. Such an
object _must_ be cache alined (and it's size rounded to a multiple
of the cache line size).

There is a simple performance reason on cache coherent archs, but
there's also the fact that it will just _not_ work properly on
non cache-coherent archs. Actually, I also have to deal with some
old machines who have a SCSI controller who has a problem accessing
buffers that aren't aligned on a cache line size boundary.

This is typically causing me trouble in various parts of SCSI which
abuses kmalloc(512, GFP_KERNEL | GFP_DMA) for buffers passed to some
SCSI commands, typically "utility" commands used to read a disk
capacity, read read/write protect flags, some sense buffers, etc...

While I know SCSI shall use the consistent alloc things, it has not
been fully fixed yet and kmalloc with GFP_DMA is still valid despite
not beeing efficient, so we should make sure in this case, the returned
buffer is really suitable for DMA, that is cache aligned.

Ben.


             reply	other threads:[~2003-08-15 16:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-15 14:00 Benjamin Herrenschmidt [this message]
2003-08-15 18:51 ` [BUG] slab debug vs. L1 alignement Philippe Elie
2003-08-15 16:54   ` Benjamin Herrenschmidt
2003-08-15 21:16 ` Andrew Morton
  -- 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
     [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
2003-08-17 17:27 James Bottomley
2003-08-18 20:29 ` Kai Makisara
2003-09-30 18:40 ` Manfred Spraul

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=1060956004.581.13.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    /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