On Tue, 20 Nov 2012 11:48:44 +0100
Marek Szyprowski wrote:
> > As this patch is already in -next and is stuck there for two more
> > weeks I can't (or at least won't) merge this patch, so I can't help
> > with any of the above.
>
> I will fix both issues in the next version of the patch. Would l
Hello,
On 11/19/2012 11:48 PM, Andrew Morton wrote:
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper wrote:
> I've added the maintainers for mm/*. Hopefully they can let us know if
> this is good for v3.8...
As Marek has inexplicably put this patch into linux-next via his tree,
we don't appea
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper wrote:
> I've added the maintainers for mm/*. Hopefully they can let us know if
> this is good for v3.8...
As Marek has inexplicably put this patch into linux-next via his tree,
we don't appear to be getting a say in the matter!
The patch looks g
Marek,
I've added the maintainers for mm/*. Hopefully they can let us know if
this is good for v3.8...
thx,
Jason.
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
> the flags provided by the caller.
On 12.11.2012 11:38, Andrew Lunn wrote:
On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
On 11.11.2012 18:22, Andrew Lunn wrote:
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
the flags
On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
> On 11.11.2012 18:22, Andrew Lunn wrote:
> > On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> >> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless
> >> the flags provided by the caller. This
On 11.11.2012 18:22, Andrew Lunn wrote:
> On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
>> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless
>> the flags provided by the caller. This causes excessive pruning of
>> emergency memory pools without any go
On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
> the flags provided by the caller. This causes excessive pruning of
> emergency memory pools without any good reason. This patch changes the code
> to corr
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
the flags provided by the caller. This causes excessive pruning of
emergency memory pools without any good reason. This patch changes the code
to correctly use gfp flags provided by the dmapool caller. This should
solve the
9 matches
Mail list logo