Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1518544167.3715.180.camel@gmail.com>
Subject: Re: lost connection to test machine (4)
From:   Eric Dumazet <eric.dumazet@gmail.com>
To:     Dennis Zhou <dennisszhou@gmail.com>
Cc:     Tejun Heo <tj@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>,
        Dmitry Vyukov <dvyukov@google.com>,
        syzbot <syzbot+adb03f3f0bb57ce3acda@syzkaller.appspotmail.com>,
        Alexei Starovoitov <ast@kernel.org>,
        netdev <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller-bugs@googlegroups.com
Date:   Tue, 13 Feb 2018 09:49:27 -0800
In-Reply-To: <20180213173438.GA60641@localhost.uwnet.wisc.edu>
References: <001a113f8734783e94056505f8fd@google.com>
         <CACT4Y+ZBHw7VZBFOeqLmrpmzgn4owW88qvP5v=xnr9966hbM_Q@mail.gmail.com>
         <00c45ca8-305d-1818-e974-a9903c8494b8@iogearbox.net>
         <20180212170325.GW695913@devbig577.frc2.facebook.com>
         <20180212200548.GG695913@devbig577.frc2.facebook.com>
         <1518528926.3715.173.camel@gmail.com>
         <20180213173438.GA60641@localhost.uwnet.wisc.edu>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2018-02-13 at 11:34 -0600, Dennis Zhou wrote:
> Hi Eric,
> 
> On Tue, Feb 13, 2018 at 05:35:26AM -0800, Eric Dumazet wrote:
> > 
> > Also I would consider using this fix as I had warnings of cpus being
> > stuck there for more than 50 ms :
> > 
> > 
> > diff --git a/mm/percpu-vm.c b/mm/percpu-vm.c
> > index 9158e5a81391ced4e268e3d5dd9879c2bc7280ce..6309b01ceb357be01e857e5f899429403836f41f 100644
> > --- a/mm/percpu-vm.c
> > +++ b/mm/percpu-vm.c
> > @@ -92,6 +92,7 @@ static int pcpu_alloc_pages(struct pcpu_chunk *chunk,
> >  			*pagep = alloc_pages_node(cpu_to_node(cpu), gfp, 0);
> >  			if (!*pagep)
> >  				goto err;
> > +			cond_resched();
> >  		}
> >  	}
> >  	return 0;
> > 
> > 
> 
> This function gets called from pcpu_populate_chunk while holding the
> pcpu_alloc_mutex and is called from two scenarios. First, when an
> allocation occurs to a place without backing pages, and second when the
> workqueue item is scheduled to replenish the number of empty pages. So,
> I don't think this is a good idea.
> 

That _is_ a good idea, we do this already in vmalloc(), and vmalloc()
can absolutely be called while some mutex(es) are held.


> My understanding is if we're seeing warnings here, that means we're
> struggling to find backing pages. I believe adding __GFP_NORETRY on the
> workqueue path as Tejun mentioned above would help with warnings as
> well, but not if they are caused by the allocation path.
> 

That is a separate concern.

My patch simply avoids latency spikes when huge percpu allocations are
happening, on systems with say 1024 cpus.