From: Jens Axboe <axboe@suse.de>
To: "Gérard Roudier" <groudier@free.fr>
Cc: "David S. Miller" <davem@redhat.com>,
gibbs@scsiguy.com, LB33JM16@yahoo.com,
linux-kernel@vger.kernel.org
Subject: Re: highmem, aic7xxx, and vfat: too few segs for dma mapping
Date: Wed, 12 Dec 2001 10:36:54 +0100 [thread overview]
Message-ID: <20011212093654.GA13498@suse.de> (raw)
In-Reply-To: <20011210.221231.72737317.davem@redhat.com> <20011211171832.R1848-100000@gerard>
In-Reply-To: <20011211171832.R1848-100000@gerard>
On Tue, Dec 11 2001, Gérard Roudier wrote:
> On Mon, 10 Dec 2001, David S. Miller wrote:
>
> > From: Gérard Roudier <groudier@free.fr>
> > Date: Mon, 10 Dec 2001 20:21:21 +0100 (CET)
> >
> > Btw, a 16 MB boundary limitation would have no significant impact on
> > performance and would have the goodness of avoiding some hardware bugs not
> > only on a few Symbios devices in my opinion. As we know, numerous modern
> > cores still have rests of the ISA epoch in their guts. So, in my opinion,
> > the 16 MB boundary limitation should be the default on systems where
> > reliability is the primary goal.
> >
> > Complications arrive when IOMMU starts to remap things into a virtual
> > 32-bit bus space as happens on several platforms now.
> >
> > Jen's block layer knows nothing about what we will do here, since
> > he only really has access to physical addresses.
> >
> > Only after the pci_map_sg() call can you inspect DMA addresses and
> > apply such workarounds.
>
> Such workaround will add bloat on the already bloated for no relevant
> reason 'generic scatter to physical' thing.
>
> As you know, low-level drivers on Linux announce some maximum length for
> the sg array. As you guess, in the worst case, each sg entry may have to
> be cut into several real entry (hoped 2 maximum) due to boundary
> limitations. At a first glance, low-level drivers should announce no more
> than half their real sg length capability and also would have to rewalk
> the entire sg list.
That's why these boundary limitations need to be known by the layer
build the requests for you.
> I used and was happy to do so when the scatter process was not generic.
> If we want it to be generic, then we want it to do the needed work. If
> generic means 'just bloated and clueless' then generic is a extreme bad
> thing.
>
> 'virt_to_bus' + 'flat addressing model' was the 'just as complex as
> needed' for DMA model and most (may-be > 99%) of existing physical
> machines are just happy with such model. The DMA/BUS complexity all O/Ses
> have invented nowadays is a useless misfeature when based on the reality,
> in my opinion. So, I may just be dreaming, at the moment. :-)
>
> If one really wants for some marketing reason to support these ugly and
> stinky '32 bit machines that want to provide more than 4GB of memory by
> shoe-horning complexity all over the place', one should use his brain,
> when so-featured, prior to writing clueless code.
First of all, virt_to_bus just cannot work on some archetectures that
are just slightly more advanced than x86. I'm quite sure Davem is ready
to lecture you on this.
Second, you are misunderstanding the need of a page/offset instead of
virtua_address model. It's _not_ for > 4GB machines, it's for machines
with highmem. You'll need this on the standard kernel to I/O above
860MB, that that is definitely a much bigger part of the market. Heck,
lots of home users have 1GB or more with the RAM prices these days.
--
Jens Axboe
next prev parent reply other threads:[~2001-12-12 9:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-10 1:32 highmem, aic7xxx, and vfat: too few segs for dma mapping LBJM
2001-12-10 18:40 ` Justin T. Gibbs
2001-12-10 19:21 ` Jens Axboe
2001-12-10 19:50 ` Justin T. Gibbs
2001-12-10 20:03 ` Jens Axboe
2001-12-10 19:21 ` Gérard Roudier
2001-12-11 6:12 ` David S. Miller
2001-12-11 17:01 ` Gérard Roudier
2001-12-12 9:36 ` Jens Axboe [this message]
2001-12-12 13:32 ` Andrea Arcangeli
2001-12-12 17:22 ` Gérard Roudier
2001-12-12 22:19 ` Andrea Arcangeli
2001-12-12 20:24 ` Gérard Roudier
2001-12-13 0:26 ` David S. Miller
2001-12-13 16:17 ` Gérard Roudier
2001-12-13 20:30 ` David S. Miller
2001-12-13 18:13 ` Gérard Roudier
2001-12-13 0:06 ` David S. Miller
2001-12-13 16:39 ` Gérard Roudier
2001-12-12 16:39 ` Gérard Roudier
2001-12-13 20:10 ` Steve Lord
2001-12-13 20:15 ` Justin T. Gibbs
2001-12-13 20:29 ` Steve Lord
2001-12-13 20:48 ` Justin T. Gibbs
2001-12-13 20:58 ` Steve Lord
2001-12-13 21:17 ` Steve Lord
2001-12-13 21:27 ` David S. Miller
2001-12-14 15:16 ` Jens Axboe
2001-12-14 16:15 ` Jens Axboe
2001-12-14 16:22 ` Alok K. Dhir
2001-12-14 16:32 ` Jens Axboe
2001-12-14 16:25 ` Stephen Lord
2001-12-14 16:24 ` Jens Axboe
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=20011212093654.GA13498@suse.de \
--to=axboe@suse.de \
--cc=LB33JM16@yahoo.com \
--cc=davem@redhat.com \
--cc=gibbs@scsiguy.com \
--cc=groudier@free.fr \
--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