This patch is very helpful and necessary since several users complained
about the failure caused by not enough low mem. And the default value
256M is suitable since the testing data showed it's sufficient
now and should be save for a long time.
And it also makes sense to supress the warning from buddy allocation
failure which will call dump_stack in x86_swiotlb_alloc_coherent. Since
it tried buddy allocation several times before the final try of bounce
buffer allocation.
So ack the whole patch set.
Acked-by: Baoquan He <[email protected]>
Hi Joerg,
Thanks for your effort on this issue.
Could you please also update the cover letter or patch log to tell
how 256M comes out with the later test result? I think it is convincing
and helpful to understand.
Thanks
Baoquan
On 01/06/15 at 03:51pm, Joerg Roedel wrote:
> v1->v2:
>
> * Updated comments based on feedback from Konrad
> * Added Acked-bys
> * Rebased to v3.19-rc3
>
> Hi,
>
> here is a patch-set to fix failed kdump kernel boots when
> the systems was booted with crashkernel=X,high. On those
> systems the kernel allocates only 72MiB of low-memory for
> DMA buffers, which showed to be too low on some systems.
>
> The problem is that 64MiB of the low-memory is allocated by
> swiotlb, leaving 8MB for the page-allocator. But swiotlb
> tries to allocate DMA memory from the page-allocator first,
> which fails pretty fast in the boot sequence, causing
> warnings. This patch-set removes these warnings.
>
> But even the 64MiB for swiotlb are eaten up on some systems,
> so that the default of low-memory allocated for the
> crash-kernel is increase from 72MB to 256MB (only changing
> the defaults, can still be overwritten by crashkernel=X,low).
>
> This number comes from experiments on the affected systems,
> 128MiB low-memory was still not enough there, thus I set the
> value to 256MiB to fix the issues.
>
> Any feedback appreciated.
>
> Thanks,
>
> Joerg
>
> Joerg Roedel (3):
> swiotlb: Warn on allocation failure in swiotlb_alloc_coherent
> x86, swiotlb: Try coherent allocations with __GFP_NOWARN
> x86, crash: Allocate enough low-mem when crashkernel=high
>
> arch/x86/kernel/pci-swiotlb.c | 8 ++++++++
> arch/x86/kernel/setup.c | 5 ++++-
> lib/swiotlb.c | 11 +++++++++--
> 3 files changed, 21 insertions(+), 3 deletions(-)
>
> --
> 1.9.1
>
> Joerg Roedel (3):
> swiotlb: Warn on allocation failure in swiotlb_alloc_coherent
> x86, swiotlb: Try coherent allocations with __GFP_NOWARN
> x86, crash: Allocate enough low-mem when crashkernel=high
>
> arch/x86/kernel/pci-swiotlb.c | 8 ++++++++
> arch/x86/kernel/setup.c | 5 ++++-
> lib/swiotlb.c | 11 +++++++++--
> 3 files changed, 21 insertions(+), 3 deletions(-)
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi Baoquan,
On Sat, Feb 14, 2015 at 06:58:34PM +0800, Baoquan He wrote:
> This patch is very helpful and necessary since several users complained
> about the failure caused by not enough low mem. And the default value
> 256M is suitable since the testing data showed it's sufficient
> now and should be save for a long time.
>
> And it also makes sense to supress the warning from buddy allocation
> failure which will call dump_stack in x86_swiotlb_alloc_coherent. Since
> it tried buddy allocation several times before the final try of bounce
> buffer allocation.
>
> So ack the whole patch set.
>
> Acked-by: Baoquan He <[email protected]>
Thanks a lot!
> Hi Joerg,
>
> Thanks for your effort on this issue.
>
> Could you please also update the cover letter or patch log to tell
> how 256M comes out with the later test result? I think it is convincing
> and helpful to understand.
Sure thing, will update the patch description before I resend the
series.
Regards,
Joerg
On 02/14/15 at 05:11pm, Joerg Roedel wrote:
> Hi Baoquan,
>
> On Sat, Feb 14, 2015 at 06:58:34PM +0800, Baoquan He wrote:
> > This patch is very helpful and necessary since several users complained
> > about the failure caused by not enough low mem. And the default value
> > 256M is suitable since the testing data showed it's sufficient
> > now and should be save for a long time.
> >
> > And it also makes sense to supress the warning from buddy allocation
> > failure which will call dump_stack in x86_swiotlb_alloc_coherent. Since
> > it tried buddy allocation several times before the final try of bounce
> > buffer allocation.
> >
> > So ack the whole patch set.
> >
> > Acked-by: Baoquan He <[email protected]>
>
> Thanks a lot!
>
> > Hi Joerg,
> >
> > Thanks for your effort on this issue.
> >
> > Could you please also update the cover letter or patch log to tell
> > how 256M comes out with the later test result? I think it is convincing
> > and helpful to understand.
>
> Sure thing, will update the patch description before I resend the
> series.
Hi Joerg,
Ping!
About this patchset, what's your plan?
Thanks
Baoquan
Hi Baoquan
On Tue, Jun 02, 2015 at 04:54:01PM +0800, Baoquan He wrote:
> Ping!
>
> About this patchset, what's your plan?
Sorry, this went out of my scope. Thanks for reminding me, I'll send a
new version soon.
Joerg