[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8AFC7968D54FB448A30D8F38F259C5622C0BD022@TK5EX14MBXC116.redmond.corp.microsoft.com>
Date: Tue, 14 Dec 2010 00:11:23 +0000
From: Hank Janssen <hjanssen@...rosoft.com>
To: Jesper Juhl <jj@...osbits.net>,
Ky Srinivasan <ksrinivasan@...ell.com>
CC: "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
"gregkh@...e.de" <gregkh@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Evgeniy Polyakov <zbr@...emap.net>,
"Haiyang Zhang" <haiyangz@...rosoft.com>
Subject: RE: [PATCH 1/1] hv: Use only one receive buffer per channel and
kmalloc on initialize
> -----Original Message-----
> From: Jesper Juhl [mailto:jj@...osbits.net]
> Sent: Monday, December 13, 2010 3:51 PM
> To: Ky Srinivasan
> > > + shut_txf_buf = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> > > + time_txf_buf = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> > > + hbeat_txf_buf = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> > Why are these allocations GFP_ATOMIC. Clearly this is in module
> loading context and you can afford to sleep. GFP_KERNEL should be fine.
> >
>
> I actually also noticed this when I did my first review of the patch,
> but
> I didn't point it out since I thought that "there must be a good
> reason".
> But now that you point it out and I look at the code once more I can't
> actually think of a "good reason",, so I agree with you completely that
> these should just be GFP_KERNEL.
I was looking at some of the back code to make sure it is okay, and I see
No reason not make this change either. I will change it and resubmit.
Thanks,
Hank.
--
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