On Fri, Sep 01, 2017 at 09:41:56AM +0200, Jesper Dangaard Brouer wrote:
> On Thu, 31 Aug 2017 18:23:49 +0200 Michal Kubecek wrote:
>
> > If we go this way (which would IMHO require some benchmarks to make sure
> > it doesn't harm performance too much) we can drop the explicit checks
> > for zero
On Thu, 31 Aug 2017 18:23:49 +0200 Michal Kubecek wrote:
> If we go this way (which would IMHO require some benchmarks to make sure
> it doesn't harm performance too much) we can drop the explicit checks
> for zero thresholds which were added to work around the unreliability of
> fast checks of
el.org; Florian Westphal
> > Subject: Re: [RFC PATCH] net: frag limit checks need to use
> > percpu_counter_compare
> >
> > On Thu, Aug 31, 2017 at 12:20:19PM +0200, Jesper Dangaard Brouer wrote:
> > > To: Liujian can you please test this patch?
> > >
Best Regards,
liujian
> -Original Message-
> From: Michal Kubecek [mailto:mkube...@suse.cz]
> Sent: Friday, September 01, 2017 12:24 AM
> To: Jesper Dangaard Brouer
> Cc: liujian (CE); netdev@vger.kernel.org; Florian Westphal
> Subject: Re: [RFC PATCH] net: frag li
On Thu, Aug 31, 2017 at 12:20:19PM +0200, Jesper Dangaard Brouer wrote:
> To: Liujian can you please test this patch?
> I want to understand if using __percpu_counter_compare() solves
> the problem correctness wise (even-though this will be slower
> than using a simple atomic_t on your big syste
On Thu, 31 Aug 2017 12:20:19 +0200
Jesper Dangaard Brouer wrote:
> +static inline bool frag_mem_over_limit(struct netns_frags *nf, int thresh)
> {
> - return percpu_counter_read(&nf->mem);
> + /* When reading counter here, __percpu_counter_compare() call
> + * will invoke __percpu_c
To: Liujian can you please test this patch?
I want to understand if using __percpu_counter_compare() solves
the problem correctness wise (even-though this will be slower
than using a simple atomic_t on your big system).
Fix bug in fragmentation codes use of the percpu_counter API, that
cause is
