All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: linux-mm@kvack.org
Subject: Re: 2.5.47-mm2
Date: Wed, 13 Nov 2002 13:40:28 -0800	[thread overview]
Message-ID: <3DD2C6CC.F831A6F2@digeo.com> (raw)
In-Reply-To: 20021113212252.GW22031@holomorphy.com

William Lee Irwin III wrote:
> 
> On Wed, Nov 13, 2002 at 12:45:07AM -0800, Andrew Morton wrote:
> >>> page-reservation.patch
> >>>   Page reservation API
> 
> William Lee Irwin III wrote:
> >> Don't drop it yet, I've got a caller of this on the back burner.
> 
> On Wed, Nov 13, 2002 at 09:12:15AM -0800, Andrew Morton wrote:
> > Well so have I.  Right now, if pte_chain_alloc() fails the
> > kernel oopses.
> 
> That's the one. I keep choking on mm/slab.c though. =(
> 

Well my plan here is to go to all code paths which end up allocating
a pte chain and do:

	reserve_local_pages(GFP_KERNEL, 2);
	spin_lock(some_lock);
	<lotsa code>
	pte_alloc_map();	/* That's one */
	pte_chain_alloc();	/* That's two */
	spin_unlock(some_lock);
	release_local_pages(GFP_KERNEL, 2);

When you're inside reserve_local_pages(), you are running atomically:
preempt is disabled.  Because the reserved pages are per-cpu.

Consequently all those pagetable allocation functions can no longer
use GFP_KERNEL and they can not have their sleep-and-try-again
stuff.  They must be atomic.  That's why the above code reserved
a page for them too.

This assumes that every architecture's pagetable allocation code
only uses zero-order pages.  If that's not true I am screwed.

Only allocations which use __GFP_RESERVE may dip into those pages.

With this we _could_ take out all the (nasty) dropping of page_table_lock
everywhere where we allocate a pagetable page.  But I figured
I'd keep that there because it works, and memsetting a whole page
while holding page_table_lock is unfriendly.


A similar bunch-o-crap needs to be done for ratnode allocations.

It isn't going to be pretty, but I haven't really been able to
come up with anything better.  A per-task reserved page pool
would not be very good - either we pin boatloads of memory or
we do tons more allocations and frees than necessary...

What do you think?
--
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-mm.org/

      reply	other threads:[~2002-11-13 21:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-13  8:45 2.5.47-mm2 Andrew Morton
2002-11-13  8:45 ` 2.5.47-mm2 Andrew Morton
2002-11-13  9:11 ` 2.5.47-mm2 William Lee Irwin III
2002-11-13  9:11   ` 2.5.47-mm2 William Lee Irwin III
2002-11-13 17:12   ` 2.5.47-mm2 Andrew Morton
2002-11-13 21:22     ` 2.5.47-mm2 William Lee Irwin III
2002-11-13 21:40       ` Andrew Morton [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=3DD2C6CC.F831A6F2@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-mm@kvack.org \
    --cc=wli@holomorphy.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.