Re: [PATCH 1/1] KVM: async_pf: do not warn on page allocation failures

[Dominik Dingel <dingel@linux.vnet.ibm.com>]

On Fri, 19 Feb 2016 13:11:46 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> In async_pf we try to allocate with NOWAIT to get an element quickly
> or fail. This code also handle failures gracefully. Lets silence
> potential page allocation failures under load.
> 
> qemu-system-s39: page allocation failure: order:0,mode:0x2200000
> [...]
> Call Trace:
> ([<00000000001146b8>] show_trace+0xf8/0x148)
> [<000000000011476a>] show_stack+0x62/0xe8
> [<00000000004a36b8>] dump_stack+0x70/0x98
> [<0000000000272c3a>] warn_alloc_failed+0xd2/0x148
> [<000000000027709e>] __alloc_pages_nodemask+0x94e/0xb38
> [<00000000002cd36a>] new_slab+0x382/0x400
> [<00000000002cf7ac>] ___slab_alloc.constprop.30+0x2dc/0x378
> [<00000000002d03d0>] kmem_cache_alloc+0x160/0x1d0
> [<0000000000133db4>] kvm_setup_async_pf+0x6c/0x198
> [<000000000013dee8>] kvm_arch_vcpu_ioctl_run+0xd48/0xd58
> [<000000000012fcaa>] kvm_vcpu_ioctl+0x372/0x690
> [<00000000002f66f6>] do_vfs_ioctl+0x3be/0x510
> [<00000000002f68ec>] SyS_ioctl+0xa4/0xb8
> [<0000000000781c5e>] system_call+0xd6/0x264
> [<000003ffa24fa06a>] 0x3ffa24fa06a
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  virt/kvm/async_pf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> index 3531599..db2dd33 100644
> --- a/virt/kvm/async_pf.c
> +++ b/virt/kvm/async_pf.c
> @@ -172,7 +172,7 @@ int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, unsigned long hva,
>  	 * do alloc nowait since if we are going to sleep anyway we
>  	 * may as well sleep faulting in page
>  	 */
> -	work = kmem_cache_zalloc(async_pf_cache, GFP_NOWAIT);
> +	work = kmem_cache_zalloc(async_pf_cache, GFP_NOWAIT | __GFP_NOWARN);
>  	if (!work)
>  		return 0;
> 

I would assume that every caller setting NOWAIT should set __GFP_NOWARN.
While most do, some don't..

For now it is fixing the problem at hand.

Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>