search for: ewma_add

...+ est_buffer_len = page_private(page); > + if (est_buffer_len > len) { > + u32 truesize_delta = est_buffer_len - len; > + > + curr_skb->truesize += truesize_delta; > + if (curr_skb != head_skb) > + head_skb->truesize += truesize_delta; > + } > + } > + ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); Hi, I looked at how ewma works, and although it is computationally efficient, and it does what it is supposed to do, initially (at the first samples) it is strongly biased towards the value that was added at the first ewma_add. I suggest that you pr...

...+ est_buffer_len = page_private(page); > + if (est_buffer_len > len) { > + u32 truesize_delta = est_buffer_len - len; > + > + curr_skb->truesize += truesize_delta; > + if (curr_skb != head_skb) > + head_skb->truesize += truesize_delta; > + } > + } > + ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); Hi, I looked at how ewma works, and although it is computationally efficient, and it does what it is supposed to do, initially (at the first samples) it is strongly biased towards the value that was added at the first ewma_add. I suggest that you pr...

Sorry, just realized - I think disabling NAPI is necessary but not sufficient. There is also the issue that refill_work() could be scheduled. If refill_work() executes, it will re-enable NAPI. We'd need to cancel the vi->refill delayed work to prevent this AFAICT, and also ensure that no other function re-schedules vi->refill or re-enables NAPI (virtnet_open/close, virtnet_set_queues,

Sorry, just realized - I think disabling NAPI is necessary but not sufficient. There is also the issue that refill_work() could be scheduled. If refill_work() executes, it will re-enable NAPI. We'd need to cancel the vi->refill delayed work to prevent this AFAICT, and also ensure that no other function re-schedules vi->refill or re-enables NAPI (virtnet_open/close, virtnet_set_queues,

On Wed, 2013-11-13 at 10:47 +0200, Ronen Hod wrote: > I looked at how ewma works, and although it is computationally efficient, > and it does what it is supposed to do, initially (at the first samples) it is strongly > biased towards the value that was added at the first ewma_add. > I suggest that you print the values of ewma_add() and ewma_read(). If you are > happy with the results, then ignore my comments. If you are not, then I can > provide a version that does better for the first samples. > Unfortunately, it will be slightly less efficient. Value is clamp...

...s reading a value that might be updated ? This is purely a debugging utility. As soon as you read the value, it might already have changed anyway. Its a integer, just read it without special care. atomic_read() has also same 'problem', and we do not care. Make sure that a recompute (aka ewma_add()) does not store intermediate wrong values, by using ACCESS_ONCE(), and thats enough. No need for the seqcount overhead. diff --git a/lib/average.c b/lib/average.c index 99a67e662b3c..044e0b7f28a8 100644 --- a/lib/average.c +++ b/lib/average.c @@ -53,8 +53,10 @@ EXPORT_SYMBOL(ewma_init); */ st...

To ensure ewma_read() without a lock returns a valid but possibly out of date average, modify ewma_add() by using ACCESS_ONCE to prevent intermediate wrong values from being written to avg->internal. Suggested-by: Eric Dumazet <eric.dumazet at gmail.com> Signed-off-by: Michael Dalton <mwdalton at google.com> --- lib/average.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(...

...; On Wed, 2013-11-13 at 10:47 +0200, Ronen Hod wrote: > >> I looked at how ewma works, and although it is computationally efficient, >> and it does what it is supposed to do, initially (at the first samples) it is strongly >> biased towards the value that was added at the first ewma_add. >> I suggest that you print the values of ewma_add() and ewma_read(). If you are >> happy with the results, then ignore my comments. If you are not, then I can >> provide a version that does better for the first samples. >> Unfortunately, it will be slightly less efficient....

...; On Wed, 2013-11-13 at 10:47 +0200, Ronen Hod wrote: > >> I looked at how ewma works, and although it is computationally efficient, >> and it does what it is supposed to do, initially (at the first samples) it is strongly >> biased towards the value that was added at the first ewma_add. >> I suggest that you print the values of ewma_add() and ewma_read(). If you are >> happy with the results, then ignore my comments. If you are not, then I can >> provide a version that does better for the first samples. >> Unfortunately, it will be slightly less efficient....

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

...ue_stats *rq_stats = vi->rq_stats[vq2rxq(rq->vq)]; int num_buf = hdr->mhdr.num_buffers; struct page *page = virt_to_head_page(ctx->buf); int offset = ctx->buf - page_address(page); @@ -413,7 +449,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev, } } - ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); + write_seqcount_begin(&rq_stats->dbg_seq); + ewma_add(&rq_stats->avg_pkt_len, head_skb->len); + write_seqcount_end(&rq_stats->dbg_seq); return head_skb; err_skb: @@ -600,18 +638,30 @@ static int add_recvbuf_big(struct rec...

...+= truesize_delta; > > + if (curr_skb != head_skb) > > + head_skb->truesize += truesize_delta; > > + } > > Is there a chance that est_buffer_len was smaller than or equal with len? Yes, and in this case we do not really care, see below. > > + } > > + ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); > > return 0; > > } > > > > @@ -382,16 +404,21 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len) > > skb_trim(skb, len); > > } else if (vi->mergeable_rx_bufs) { > >...

...ge packet length for mergeable receive buffers. */ - struct ewma mrg_avg_pkt_len; + struct ewma_pkt_len mrg_avg_pkt_len; /* Page frag for packet buffer allocation. */ struct page_frag alloc_frag; @@ -407,7 +407,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev, } } - ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); + ewma_pkt_len_add(&rq->mrg_avg_pkt_len, head_skb->len); return head_skb; err_skb: @@ -600,12 +600,12 @@ static int add_recvbuf_big(struct virtnet_info *vi, struct receive_queue *rq, return err; } -static unsigned int get_mergeable...

...ge packet length for mergeable receive buffers. */ - struct ewma mrg_avg_pkt_len; + struct ewma_pkt_len mrg_avg_pkt_len; /* Page frag for packet buffer allocation. */ struct page_frag alloc_frag; @@ -407,7 +407,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev, } } - ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); + ewma_pkt_len_add(&rq->mrg_avg_pkt_len, head_skb->len); return head_skb; err_skb: @@ -600,12 +600,12 @@ static int add_recvbuf_big(struct virtnet_info *vi, struct receive_queue *rq, return err; } -static unsigned int get_mergeable...

...is enforced by virtio-net + * and NAPI. + */ + seqcount_t sysfs_seq; + /* Page frag for packet buffer allocation. */ struct page_frag alloc_frag; @@ -416,7 +423,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev, } } + write_seqcount_begin(&rq->sysfs_seq); ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); + write_seqcount_end(&rq->sysfs_seq); return head_skb; err_skb: @@ -604,18 +613,29 @@ static int add_recvbuf_big(struct receive_queue *rq, gfp_t gfp) return err; } -static int add_recvbuf_mergeable(struct receive_queue *rq, gfp_t gfp)...

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

...) { > + u32 truesize_delta = est_buffer_len - len; > + > + curr_skb->truesize += truesize_delta; > + if (curr_skb != head_skb) > + head_skb->truesize += truesize_delta; > + } Is there a chance that est_buffer_len was smaller than or equal with len? > + } > + ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); > return 0; > } > > @@ -382,16 +404,21 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len) > skb_trim(skb, len); > } else if (vi->mergeable_rx_bufs) { > struct page *page = virt_to_hea...

...) { > + u32 truesize_delta = est_buffer_len - len; > + > + curr_skb->truesize += truesize_delta; > + if (curr_skb != head_skb) > + head_skb->truesize += truesize_delta; > + } Is there a chance that est_buffer_len was smaller than or equal with len? > + } > + ewma_add(&rq->mrg_avg_pkt_len, head_skb->len); > return 0; > } > > @@ -382,16 +404,21 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len) > skb_trim(skb, len); > } else if (vi->mergeable_rx_bufs) { > struct page *page = virt_to_hea...