[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1245059324.23207.13.camel@penberg-laptop>
Date: Mon, 15 Jun 2009 12:48:44 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: Nick Piggin <npiggin@...e.de>
Cc: Heiko Carstens <heiko.carstens@...ibm.com>,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, cl@...ux-foundation.org,
kamezawa.hiroyu@...fujitsu.com, lizf@...fujitsu.com, mingo@...e.hu,
yinghai@...nel.org, benh@...nel.crashing.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31
Hi Nick,
On Mon, Jun 15, 2009 at 11:18 AM, Heiko Carstens<heiko.carstens@...ibm.com> wrote:
> > > I didn't look any deeper into this, but looks to me like doing something like
> > > schedule_work() this early isn't ok.
> > >
> > > This is the conversion that leads to the crash:
> > >
> > > - alloc_bootmem_low(sizeof(struct raw3215_info));
> > > + kzalloc(sizeof(struct raw3215_info), GFP_NOWAIT | GFP_DMA);
> > >
> > > Might be that I missed something. Maybe some special flag?
On Mon, Jun 15, 2009 at 12:10:01PM +0300, Pekka Enberg wrote:
> > Btw, you should not need to use GFP_NOWAIT anymore and GFP_KERNEL
> > should be fine even during early boot.
On Mon, 2009-06-15 at 11:41 +0200, Nick Piggin wrote:
> Is this the agreed way forward? I would like to maybe continue to
> try having early allocations pass in special flags where possible
> (it could even be a GFP_BOOT or something). It can make it easier
> to perhaps reduce branches in core code in future and things can
> be flagged in warnings....
>
> I just like the idea of keeping such annotations.
I don't know if we agreed or not but Linus expressed his liking to the
masking patch (that is merged now).
I was more on the GFP_BOOT side also but I am beginning to like the fact
that we can just do GFP_KERNEL and expect that to work in a sane way
during boot (and perhaps later on during suspend). We can probably shave
off even more cycles for production configs if we push the masking down
to the page allocator so I am not sure if extra cycles are going to be a
real issue.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists