From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: Manfred Spraul <manfred@colorfullife.com>,
linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] slab debug vs. L1 alignement
Date: 16 Aug 2003 13:36:30 +0200 [thread overview]
Message-ID: <1061033789.582.126.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.56.0308161359460.1703@kai.makisara.local>
> ->
> A character device (like st) doing direct i/o from user buffer to/from a
> SCSI device does not currently have any alignment restrictions. I think
> restricted alignment can't be required from a user of an ordinary
> character device. This must then be handled by the driver. The solution is
> to use bounce buffers in the driver if the alignment does not meet the
> lower level requirements. This leads to surprises with performance if the
> user buffer alignment does not satisfy the requirements (e.g., malloc()
> may or may not return properly aligned blocks). These surprises should be
> avoided as far as the hardware allows.
THe low level driver can't do the bounce buffer thing, it has to be
done at higher layers.
> If an architecture has restrictions, they must, of course, be taken into
> account. However, this should not punish architectures that don't have the
> restrictions. Specifying that DMA buffers must be cache-line aligned would
> be too strict. A separate alignment constraint for DMA in general and for
> a device in specific would be a better alternative (a device may have
> tighter restrictions than an architecture). The same applies to buffer
> sizes. This would mean adding two more masks for each device (like the
> current DMA address mask for a device).
That won't help for buffers coming from higher layers that don't know
the device they'll end up to
Ben.
next prev parent reply other threads:[~2003-08-16 11:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-15 21:50 [BUG] slab debug vs. L1 alignement 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 [this message]
2003-08-16 14:39 ` Kai Makisara
-- strict thread matches above, loose matches on Subject: below --
2003-08-17 17:27 James Bottomley
2003-08-18 20:29 ` 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
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=1061033789.582.126.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=Kai.Makisara@kolumbus.fi \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.