All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ingo Molnar <mingo@elte.hu>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	linux-kernel@vger.kernel.org, chrisw@sous-sol.org,
	dwmw2@infradead.org, joerg.roedel@amd.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Yinghai Lu <yinghai@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Vegard Nossum <vegard.nossum@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 07/10] bootmem: add free_bootmem_late
Date: Wed, 28 Oct 2009 13:12:49 +0100	[thread overview]
Message-ID: <4AE83541.3030306@kernel.org> (raw)
In-Reply-To: <84144f020910280438j65bcacacq731f6076cbd8d99@mail.gmail.com>

Hello,

Pekka Enberg wrote:
> On Wed, Oct 28, 2009 at 10:00 AM, Tejun Heo <tj@kernel.org> wrote:
>> ISTR an attempt to initialize the kmalloc allocator much earlier
>> during boot such that it can completely replace the bootmem allocator,
>> which would nicely remove all the complications although it may
>> require the kmalloc allocator to go through more complex boot
>> strapping steps.  I didn't follow how that went.  Did it prove to be
>> unworkable?
> 
> We're doing it before scheduler init now but I haven't put any effort
> into moving it earlier than that yet. I don't see any fundamental
> reason we can't do that but the practical problem is that we're going
> to affect architecture specific boot code which is really hard to
> test.

Thanks for the explanation.  It would be really great if we can pull
that off someday.  This should be doable architecture-by-architecture,
right?  You can, for example, first convert x86 and then make bootmem
allocator thin wrapper around the slab allocator.  After all archs
have been converted, the wrappers can be dropped.

-- 
tejun

  reply	other threads:[~2009-10-28 12:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-28  6:47 [PATCH 0/10] x86: handle HW IOMMU initialization failure gracely FUJITA Tomonori
2009-10-28  6:47 ` [PATCH 01/10] Add iommu_init to x86_init_ops FUJITA Tomonori
2009-11-09 20:02   ` Pekka Enberg
2009-11-09 20:11     ` FUJITA Tomonori
2009-11-10  4:45       ` Ingo Molnar
2009-10-28  6:47 ` [PATCH 02/10] Calgary: convert detect_calgary to use iommu_init hook FUJITA Tomonori
2009-10-28 13:38   ` Muli Ben-Yehuda
2009-10-28  6:47 ` [PATCH 03/10] GART: convert gart_iommu_hole_init " FUJITA Tomonori
2009-10-28  6:47 ` [PATCH 04/10] amd_iommu: convert amd_iommu_detect " FUJITA Tomonori
2009-10-28  6:47 ` [PATCH 05/10] intel-iommu: convert detect_intel_iommu " FUJITA Tomonori
2009-10-28  6:47 ` [PATCH 06/10] bootmem: refactor free_all_bootmem_core FUJITA Tomonori
2009-10-28  7:34   ` Ingo Molnar
2009-10-28  7:36   ` Ingo Molnar
2009-10-28  6:47 ` [PATCH 07/10] bootmem: add free_bootmem_late FUJITA Tomonori
2009-10-28  7:48   ` Ingo Molnar
2009-10-28  8:00     ` Tejun Heo
2009-10-28 11:38       ` Pekka Enberg
2009-10-28 12:12         ` Tejun Heo [this message]
2009-10-29 11:19           ` Pekka Enberg
2009-11-08  9:57             ` Ingo Molnar
2009-11-16 10:27               ` Joerg Roedel
2009-11-06  1:50     ` FUJITA Tomonori
2009-11-08 10:00       ` Ingo Molnar
2009-11-09 19:22         ` FUJITA Tomonori
2009-11-09 20:13   ` Pekka Enberg
2009-11-09 20:21     ` Pekka Enberg
2009-11-09 21:47       ` FUJITA Tomonori
2009-11-10  8:05         ` Pekka Enberg
2009-11-13 21:11       ` Chris Wright
2009-10-28  6:47 ` [PATCH 08/10] swiotlb: add swiotlb_free function FUJITA Tomonori
2009-10-28  6:47 ` [PATCH 09/10] swiotlb: export swiotlb_print_info FUJITA Tomonori
2009-10-28  6:47 ` [PATCH 10/10] x86: handle HW IOMMU initialization failure gracely FUJITA Tomonori
2009-10-28 13:21 ` [PATCH 0/10] " Joerg Roedel
2009-10-29  8:27   ` FUJITA Tomonori

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=4AE83541.3030306@kernel.org \
    --to=tj@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=chrisw@sous-sol.org \
    --cc=dwmw2@infradead.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hpa@zytor.com \
    --cc=joerg.roedel@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vegard.nossum@gmail.com \
    --cc=yinghai@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 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.