archive mirror
 help / color / mirror / Atom feed
From: David Gibson <>
To: Russell King <>
Cc: Andrew Morton <>, David Miller <>,
	Paul Mackerras <>,,
Subject: Re: [PATCH,RFC] Add gfp_mask to get_vm_area()
Date: Fri, 4 Oct 2002 13:27:30 +1000	[thread overview]
Message-ID: <20021004032730.GL1933@zax> (raw)
In-Reply-To: <>

On Thu, Oct 03, 2002 at 04:18:16PM +0100, Russell King wrote:
> On Thu, Oct 03, 2002 at 02:56:44PM +1000, David Gibson wrote:
> > Blah.  It gets worse.  Making map_page() or remap_page_range()
> > interrupt-safe would require making mm->page_table_lock irq-safe too
> > :-(
> >
> > Maybe non-coherent architectures should should pre-allocate a chunk of
> > virtual memory for consistent allocations, and pre-allocate all its
> > page tables.
> There are a growing number of applications out there for ARM stuff where
> this would be impractical.  Those wanting about 3GB of kernel space vs
> 1GB user space.
> Doubling the virtual requirement for the SDRAM will make Linux unusable
> in these situations, and then you'll have nice people from Intel and
> Montavista banging on your door asking you why you killed their product
> line.

Well I certainly wasn't we have an additional virtual mapping for all
of physical RAM - if nothing else that would waste a bunch of space in
page tables.  I was thinking of a pool of VM out of which to establish
new consistent mappings - with a simple and irq-safe allocated working
within the pre-allocated chunk of VM.

Which of course raises the hard question: how big should the pool be?
It would be possible to have something running in user context which
tops up the pool if it is low, but that starts getting complex, and
wouldn't help a driver which wants to allocate a large chunk of
consistent memory from interrupt context.

> The current situation on ARM works for 95% of cases.  If the choice is
> between "95% working" and "cutting off the hand that feeds you" I'd
> prefer the former.
> On a more constructive note, I believe there is a way around the
> mm->page_table_lock problem.  I believe we should completely split the
> handling of the user space page tables from the kernel space page tables.
> User space can carry on using mm->page_table_lock and be happy; it should
> never ever touch the kernel page tables.
> We then only have to worry about making things that touch the kernel page
> tables irq-safe.  How many of those are there?  Two.  ioremap and vmalloc.
> Neither of these two functions has any business touching anything other
> than pid0's tables, and certainly has no business touching user space
> page tables.  The problem is now far easier to deal with.

Well, that sounds like it would work.  On the other hand, it seems
like a non-trivial set of modifications to the VM structure.

> remap_page_range() shouldn't be a problem - its supposed to map pages
> into user space, and if you're calling that from IRQ context, you're
> doing something really wrong.
> If I can get out of my current circle of never-ending problems and paid-
> for work on other areas of ARM stuff, I might be able to look at this.
> I've currently got an estimated backlog of one whole week on anything I
> do atm.

David Gibson			| For every complex problem there is a	| solution which is simple, neat and
				| wrong.

      reply	other threads:[~2002-10-04  3:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-01  4:42 [PATCH,RFC] Add gfp_mask to get_vm_area() David Gibson
2002-10-01  4:37 ` David S. Miller
2002-10-01  5:08 ` Andrew Morton
2002-10-01  5:34   ` David Gibson
2002-10-01  8:42     ` Russell King
2002-10-02  1:18       ` David Gibson
2002-10-03  4:39     ` David Gibson
2002-10-03  4:56       ` David Gibson
2002-10-03 15:18         ` Russell King
2002-10-04  3:27           ` David Gibson [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021004032730.GL1933@zax \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).