Hi Vlad and Eric,
On Tue, Jan 22, 2019 at 09:33:10AM -0800, Eric Dumazet wrote:
> On Mon, Jan 21, 2019 at 3:24 AM Vlad Buslov wrote:
> >
> > Hi Eric,
> >
> > I've been investigating significant tc filter insertion rate degradation
> > and it seems it is caused by your commit 001c96db0181 ("net: a
On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote:
>
> [ +Dennis, +Tejun ]
>
> Looks like we're stuck in percpu allocator with key/value size of 4 bytes
> each and large number of entries (max_entries) in the reproducer in above
> link.
>
> Could we have some __GFP_NORETRY semantic
On Tue, Feb 13, 2018 at 09:49:27AM -0800, Eric Dumazet wrote:
> 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
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..6309b01ceb3
Hi Daniel and Tejun,
On Wed, Oct 18, 2017 at 06:25:26AM -0700, Tejun Heo wrote:
> > Daniel Borkmann (3):
> > mm, percpu: add support for __GFP_NOWARN flag
>
> This looks fine.
>
Looks good to me too.
> > bpf: fix splat for illegal devmap percpu allocation
> > bpf: do not test for PCPU_MI
