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
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
Hello,
On 11/19/2012 11:48 PM, Andrew Morton wrote:
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper ja...@lakedaemon.net 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
On Tue, 20 Nov 2012 11:48:44 +0100
Marek Szyprowski m.szyprow...@samsung.com 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
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
On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper ja...@lakedaemon.net 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!
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.
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
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 good
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 causes
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 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
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
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
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
18 matches
Mail list logo