linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Roman Zippel <roman@augan.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	Kanoj Sarcar <kanoj@google.engr.sgi.com>,
	linux-mm@kvack.org, linux-kernel@vger.rutgers.edu,
	rmk@arm.linux.org.uk, nico@cam.org, davem@redhat.com,
	davidm@hpl.hp.com, alan@lxorguk.ukuu.org.uk
Subject: Re: pte_pagenr/MAP_NR deleted in pre6
Date: Wed, 16 Aug 2000 19:17:00 +0100	[thread overview]
Message-ID: <20000816191700.J19260@redhat.com> (raw)
In-Reply-To: <399A4FE4.FA5C397A@augan.com>; from roman@augan.com on Wed, Aug 16, 2000 at 10:25:08AM +0200

Hi,

On Wed, Aug 16, 2000 at 10:25:08AM +0200, Roman Zippel wrote:
> 
> > Excellent, this will make it _tons_ easier for me to create new zones
> > of mem_map arrays on the fly to allow us to create struct pages for
> > PCI IO-aperture memory (necessary for kiobuf mappings of IO memory).
> 
> A related question: do you already have an idea how the driver interface
> for that could look like? I mean, some drivers need a virtual address,
> some need the physical address for dma and some of them might need
> bounce buffers.

It's even more complicated than that --- you can't even assume that
the pages concerned have got valid pointers in _any_ address space,
because they might be high memory pages on PAE36 which exist above the
4GB boundary and which aren't mapped into virtual memory anywhere.

We will need to make sure that there is a clean way to convert any
struct page * into (a) a kernel virtual address (that's easy, kmap()
does it already); (b) a physical address (which can be translated
easily into a bus address); or (c) a page frame number which can
identify pages above 4GB even though a ulong pointer/address can't
cope with such pages as addresses directly.  

However, the kiobuf code will not do anything fancy with _any_ of this
--- it will continue just to carry struct page *s.  It will be up to
the users of the kiobufs to do anything further with them.  I already
have bounce buffer support for kiobufs in 2.2 (as a quick hack to let
highmem raw IO work on 2.2; 2.4 is much cleaner and doesn't need that
particular hack).  I'll make sure that 2.4 has a clean way of doing
bounce buffers too, probably by means of a clone_kiobuf() function
which creates a new kiobuf by cloning the pages of the original if
they satisfy some constraint (such as <1GB, <4GB), and
pre/post-copying them if they do not.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

      parent reply	other threads:[~2000-08-16 18:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-10 17:18 Kanoj Sarcar
2000-08-11  2:24 ` David S. Miller
2000-08-14  0:34   ` Anton Blanchard
2000-08-11 11:50 ` Roman Zippel
2000-08-11 13:20   ` Russell King
2000-08-11 14:56     ` Roman Zippel
2000-08-12  9:18       ` Bjorn Wesen
2000-08-11 17:21     ` Kanoj Sarcar
2000-08-14  9:29       ` Roman Zippel
2000-08-15 16:19 ` Stephen C. Tweedie
2000-08-16  8:25   ` Roman Zippel
2000-08-16 17:13     ` Kanoj Sarcar
2000-08-16 18:20       ` Stephen C. Tweedie
2000-08-16 18:24         ` David S. Miller
2000-08-16 19:53           ` Stephen C. Tweedie
2000-08-16 18:47         ` Kanoj Sarcar
2000-08-16 18:39           ` David S. Miller
2000-08-16 19:30             ` Stephen C. Tweedie
2000-08-16 22:22         ` Kanoj Sarcar
2000-08-17  9:11           ` Stephen C. Tweedie
2000-08-17 19:07             ` Kanoj Sarcar
2000-08-17 19:01               ` David S. Miller
2000-08-17 19:19                 ` Alan Cox
2000-08-17 19:20                   ` David S. Miller
2000-08-17 19:33                     ` Alan Cox
2000-08-17 19:36                     ` Kanoj Sarcar
2000-09-07 14:31                       ` Ralf Baechle
2000-08-17 19:50                     ` Kanoj Sarcar
2000-08-17 19:41                       ` David S. Miller
2000-09-07 14:26                         ` Ralf Baechle
2000-08-17 19:56                       ` Alan Cox
2000-08-17 19:24                   ` Alan Cox
2000-08-17 19:32                 ` Kanoj Sarcar
2000-08-17 19:30                   ` David S. Miller
2000-08-17 20:00                     ` Kanoj Sarcar
2000-08-16 18:17     ` Stephen C. Tweedie [this message]

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=20000816191700.J19260@redhat.com \
    --to=sct@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=davidm@hpl.hp.com \
    --cc=kanoj@google.engr.sgi.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=nico@cam.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=roman@augan.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