Hi Andi,
your patch 'ppc64: SPARSEMEM_VMEMMAP support' adds the following two lines:
+ printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
+ "physical %p.\n", start, p, __pa(p));
in a loop around basically every page. That's a lot of flooding (with
the wrong printk level, btw) and really slows down booting my cell blade
a lot (these only have a very slow serial over lan console).
Any reason to keep this? And if yes can we please make it conditional
on some kind of vmemmap_debug boot option?
Hi Christoph,
On Wed, 21 Nov 2007 16:35:26 +0100 Christoph Hellwig [off-list ref] wrote:
Hi Andi,
your patch 'ppc64: SPARSEMEM_VMEMMAP support' adds the following two lines:
+ printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
+ "physical %p.\n", start, p, __pa(p));
in a loop around basically every page. That's a lot of flooding (with
the wrong printk level, btw) and really slows down booting my cell blade
a lot (these only have a very slow serial over lan console).
Any reason to keep this? And if yes can we please make it conditional
on some kind of vmemmap_debug boot option?
These have been changed to pr_debug() in 2.6.24-rc3 kernel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
On Thu, Nov 22, 2007 at 09:41:45AM +1100, Stephen Rothwell wrote:
quoted
Any reason to keep this? And if yes can we please make it conditional
on some kind of vmemmap_debug boot option?
These have been changed to pr_debug() in 2.6.24-rc3 kernel.
Ah, sorry for not checking. Looks like the spufs tree lags a little
behind.