On Mon, Feb 25, 2008 at 07:00:34AM -0800, James Bottomley wrote:
>
> On Mon, 2008-02-25 at 15:56 +0100, Andi Kleen wrote:
> > On Mon, Feb 25, 2008 at 06:43:08AM -0800, James Bottomley wrote:
> > > On Mon, 2008-02-25 at 00:36 +0100, Andi Kleen wrote:
> > > > Don't use unnecessary GFP_ATOMIC in sg.c
On Mon, 2008-02-25 at 15:56 +0100, Andi Kleen wrote:
> On Mon, Feb 25, 2008 at 06:43:08AM -0800, James Bottomley wrote:
> > On Mon, 2008-02-25 at 00:36 +0100, Andi Kleen wrote:
> > > Don't use unnecessary GFP_ATOMIC in sg.c
> > >
> > > sg.c uses GFP_ATOMIC for a lot of allocations where it isn't
On Mon, Feb 25, 2008 at 06:43:08AM -0800, James Bottomley wrote:
> On Mon, 2008-02-25 at 00:36 +0100, Andi Kleen wrote:
> > Don't use unnecessary GFP_ATOMIC in sg.c
> >
> > sg.c uses GFP_ATOMIC for a lot of allocations where it isn't necessary.
> > There are no locks hold and I don't see any other
On Mon, 2008-02-25 at 00:36 +0100, Andi Kleen wrote:
> Don't use unnecessary GFP_ATOMIC in sg.c
>
> sg.c uses GFP_ATOMIC for a lot of allocations where it isn't necessary.
> There are no locks hold and I don't see any other reasons why GFP_ATOMIC
> should be needed here. So remove them for more re
> Oh no, not again. This isn't the first time kernel folks
> have tried to demote the sg driver's GFP_ATOMIC to GFP_KERNEL.
That is because it is abusing GFP_ATOMIC.
> In the past it has ended in grief. The driver was written
> to attempt _fast_ allocation and if that failed then:
You want it to
Andi Kleen wrote:
Don't use unnecessary GFP_ATOMIC in sg.c v2
[Update for the previous version of the patch]
sg.c uses GFP_ATOMIC for a lot of allocations where it isn't necessary.
There are no locks hold and I don't see any other reasons why GFP_ATOMIC
should be needed here. So remove them.
D
Don't use unnecessary GFP_ATOMIC in sg.c v2
[Update for the previous version of the patch]
sg.c uses GFP_ATOMIC for a lot of allocations where it isn't necessary.
There are no locks hold and I don't see any other reasons why GFP_ATOMIC
should be needed here. So remove them.
Depends on the earlie
Don't use unnecessary GFP_ATOMIC in sg.c
sg.c uses GFP_ATOMIC for a lot of allocations where it isn't necessary.
There are no locks hold and I don't see any other reasons why GFP_ATOMIC
should be needed here. So remove them for more reliable allocations.
Depends on the earlier GFP_DMA patchkit, b
8 matches
Mail list logo