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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox