All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Andi Kleen <ak@muc.de>
Cc: Matt Tolentino <metolent@cs.vt.edu>,
	akpm@osdl.org, discuss@x86-64.org, linux-kernel@vger.kernel.org,
	matthew.e.tolentino@intel.com
Subject: Re: [discuss] Re: [patch 3/3] add x86-64 support for memory hot-add II
Date: Fri, 9 Dec 2005 18:49:04 +0100	[thread overview]
Message-ID: <20051209174904.GA30117@brahms.suse.de> (raw)
In-Reply-To: <20051209173249.GA54033@muc.de>

> In general SRAT has a hotplug memory bit so it's possible
> to predict how much memory there will be in advance. Since
> the overhead of the kernel page tables should be very
> low I would prefer if you just used instead.
> 
> (i.e. instead of extending the kernel mapping preallocate
> the direct mapping and just clear the P bits) 
> 
> That should be much simpler.

Looking at it again - accessing SRAT currently relies on the 
direct mapping already. Untangling that would be possible,
but require an bt_ioremap which would also add lots of code.

Ok I retract that objection. I guess your way is better
for now.

In addition to the __cpuinit comment

+if (after_bootmem) spin_unlock(&init_mm.page_table_lock);

Conditional locking is evil. spinlocking in the boot
case should just work too I think.

The EXPORTs should be probably EXPORT_SYMBOL_GPL.

With these changes it would look ok for me.

-Andi

  reply	other threads:[~2005-12-09 17:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-09 15:23 [patch 3/3] add x86-64 support for memory hot-add Matt Tolentino
2005-12-09 17:32 ` Andi Kleen
2005-12-09 17:49   ` Andi Kleen [this message]
2005-12-10  0:16   ` Keith Mannthey
2005-12-10  3:26     ` [discuss] " Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2005-12-09 18:36 [discuss] Re: [patch 3/3] add x86-64 support for memory hot-add II Tolentino, Matthew E

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=20051209174904.GA30117@brahms.suse.de \
    --to=ak@suse.de \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.e.tolentino@intel.com \
    --cc=metolent@cs.vt.edu \
    /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.