Re: [PATCH net-next RFC 2/2] vhost_net: basic polling support
On Thu, Oct 22, 2015 at 01:27:29AM -0400, Jason Wang wrote: > This patch tries to poll for new added tx buffer for a while at the > end of tx processing. The maximum time spent on polling were limited > through a module parameter. To avoid block rx, the loop will end it > there's new other works queued on vhost so in fact socket receive > queue is also be polled. > > busyloop_timeout = 50 gives us following improvement on TCP_RR test: > > size/session/+thu%/+normalize% > 1/ 1/ +5%/ -20% > 1/50/ +17%/ +3% Is there a measureable increase in cpu utilization with busyloop_timeout = 0? > Signed-off-by: Jason WangWe might be able to shave off the minor regression by careful use of likely/unlikely, or maybe deferring > --- > drivers/vhost/net.c | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > index 9eda69e..bbb522a 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -31,7 +31,9 @@ > #include "vhost.h" > > static int experimental_zcopytx = 1; > +static int busyloop_timeout = 50; > module_param(experimental_zcopytx, int, 0444); > +module_param(busyloop_timeout, int, 0444); Pls add a description, including the units and the special value 0. > MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;" > " 1 -Enable; 0 - Disable"); > > @@ -287,12 +289,23 @@ static void vhost_zerocopy_callback(struct ubuf_info > *ubuf, bool success) > rcu_read_unlock_bh(); > } > > +static bool tx_can_busy_poll(struct vhost_dev *dev, > + unsigned long endtime) > +{ > + unsigned long now = local_clock() >> 10; local_clock might go backwards if we jump between CPUs. One way to fix would be to record the CPU id and break out of loop if that changes. Also - defer this until we actually know we need it? > + > + return busyloop_timeout && !need_resched() && > +!time_after(now, endtime) && !vhost_has_work(dev) && > +single_task_running(); signal pending as well? > +} > + > /* Expects to be always run from workqueue - which acts as > * read-size critical section for our kind of RCU. */ > static void handle_tx(struct vhost_net *net) > { > struct vhost_net_virtqueue *nvq = >vqs[VHOST_NET_VQ_TX]; > struct vhost_virtqueue *vq = >vq; > + unsigned long endtime; > unsigned out, in; > int head; > struct msghdr msg = { > @@ -331,6 +344,8 @@ static void handle_tx(struct vhost_net *net) > % UIO_MAXIOV == nvq->done_idx)) > break; > > + endtime = (local_clock() >> 10) + busyloop_timeout; > +again: > head = vhost_get_vq_desc(vq, vq->iov, >ARRAY_SIZE(vq->iov), >, , > @@ -340,6 +355,10 @@ static void handle_tx(struct vhost_net *net) > break; > /* Nothing new? Wait for eventfd to tell us they refilled. */ > if (head == vq->num) { > + if (tx_can_busy_poll(vq->dev, endtime)) { > + cpu_relax(); > + goto again; > + } > if (unlikely(vhost_enable_notify(>dev, vq))) { > vhost_disable_notify(>dev, vq); > continue; > -- > 1.8.3.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] VSOCK: sock_put wasn't safe to call in interrupt context
From: Jorgen HansenDate: Wed, 21 Oct 2015 04:53:56 -0700 > In the vsock vmci_transport driver, sock_put wasn't safe to call > in interrupt context, since that may call the vsock destructor > which in turn calls several functions that should only be called > from process context. This change defers the callling of these > functions to a worker thread. All these functions were > deallocation of resources related to the transport itself. > > Furthermore, an unused callback was removed to simplify the > cleanup. > > Multiple customers have been hitting this issue when using > VMware tools on vSphere 2015. > > Also added a version to the vmci transport module (starting from > 1.0.2.0-k since up until now it appears that this module was > sharing version with vsock that is currently at 1.0.1.0-k). > > Reviewed-by: Aditya Asarwade > Reviewed-by: Thomas Hellstrom > Signed-off-by: Jorgen Hansen Applied, thanks. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next RFC 1/2] vhost: introduce vhost_has_work()
On Thu, Oct 22, 2015 at 01:27:28AM -0400, Jason Wang wrote: > This path introduces a helper which can give a hint for whether or not > there's a work queued in the work list. > > Signed-off-by: Jason Wang> --- > drivers/vhost/vhost.c | 6 ++ > drivers/vhost/vhost.h | 1 + > 2 files changed, 7 insertions(+) > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c > index eec2f11..d42d11e 100644 > --- a/drivers/vhost/vhost.c > +++ b/drivers/vhost/vhost.c > @@ -245,6 +245,12 @@ void vhost_work_queue(struct vhost_dev *dev, struct > vhost_work *work) > } > EXPORT_SYMBOL_GPL(vhost_work_queue); > > +bool vhost_has_work(struct vhost_dev *dev) > +{ > + return !list_empty(>work_list); > +} > +EXPORT_SYMBOL_GPL(vhost_has_work); > + > void vhost_poll_queue(struct vhost_poll *poll) > { > vhost_work_queue(poll->dev, >work); This doesn't take a lock so it's unreliable. I think it's ok in this case since it's just an optimization - but pls document this. > diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h > index 4772862..ea0327d 100644 > --- a/drivers/vhost/vhost.h > +++ b/drivers/vhost/vhost.h > @@ -37,6 +37,7 @@ struct vhost_poll { > > void vhost_work_init(struct vhost_work *work, vhost_work_fn_t fn); > void vhost_work_queue(struct vhost_dev *dev, struct vhost_work *work); > +bool vhost_has_work(struct vhost_dev *dev); > > void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t fn, >unsigned long mask, struct vhost_dev *dev); > -- > 1.8.3.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net-next RFC 2/2] vhost_net: basic polling support
On Thu, Oct 22, 2015 at 08:46:33AM -0700, Rick Jones wrote: > On 10/22/2015 02:33 AM, Michael S. Tsirkin wrote: > >On Thu, Oct 22, 2015 at 01:27:29AM -0400, Jason Wang wrote: > >>This patch tries to poll for new added tx buffer for a while at the > >>end of tx processing. The maximum time spent on polling were limited > >>through a module parameter. To avoid block rx, the loop will end it > >>there's new other works queued on vhost so in fact socket receive > >>queue is also be polled. > >> > >>busyloop_timeout = 50 gives us following improvement on TCP_RR test: > >> > >>size/session/+thu%/+normalize% > >> 1/ 1/ +5%/ -20% > >> 1/50/ +17%/ +3% > > > >Is there a measureable increase in cpu utilization > >with busyloop_timeout = 0? > > And since a netperf TCP_RR test is involved, be careful about what netperf > reports for CPU util if that increase isn't in the context of the guest OS. > > For completeness, looking at the effect on TCP_STREAM and TCP_MAERTS, > aggregate _RR and even aggregate _RR/packets per second for many VMs on the > same system would be in order. > > happy benchmarking, > > rick jones Absolutely, merging a new kernel API just for a specific benchmark doesn't make sense. I'm guessing this is just an early RFC, a fuller submission will probably include more numbers. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization