Re: [PATCH V3 3/3] vhost_net: basic polling support
On 02/29/2016 05:56 AM, Christian Borntraeger wrote:
> On 02/26/2016 09:42 AM, Jason Wang wrote:
>> > This patch tries to poll for new added tx buffer or socket receive
>> > queue for a while at the end of tx/rx processing. The maximum time
>> > spent on polling were specified through a new kind of vring ioctl.
>> >
>> > Signed-off-by: Jason Wang
>> > ---
>> > drivers/vhost/net.c| 79
>> > +++---
>> > drivers/vhost/vhost.c | 14
>> > drivers/vhost/vhost.h | 1 +
>> > include/uapi/linux/vhost.h | 6
>> > 4 files changed, 95 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> > index 9eda69e..c91af93 100644
>> > --- a/drivers/vhost/net.c
>> > +++ b/drivers/vhost/net.c
>> > @@ -287,6 +287,44 @@ static void vhost_zerocopy_callback(struct ubuf_info
>> > *ubuf, bool success)
>> >rcu_read_unlock_bh();
>> > }
>> >
>> > +static inline unsigned long busy_clock(void)
>> > +{
>> > + return local_clock() >> 10;
>> > +}
>> > +
>> > +static bool vhost_can_busy_poll(struct vhost_dev *dev,
>> > + unsigned long endtime)
>> > +{
>> > + return likely(!need_resched()) &&
>> > + likely(!time_after(busy_clock(), endtime)) &&
>> > + likely(!signal_pending(current)) &&
>> > + !vhost_has_work(dev) &&
>> > + single_task_running();
>> > +}
>> > +
>> > +static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
>> > + struct vhost_virtqueue *vq,
>> > + struct iovec iov[], unsigned int iov_size,
>> > + unsigned int *out_num, unsigned int *in_num)
>> > +{
>> > + unsigned long uninitialized_var(endtime);
>> > + int r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
>> > + out_num, in_num, NULL, NULL);
>> > +
>> > + if (r == vq->num && vq->busyloop_timeout) {
>> > + preempt_disable();
>> > + endtime = busy_clock() + vq->busyloop_timeout;
>> > + while (vhost_can_busy_poll(vq->dev, endtime) &&
>> > + vhost_vq_avail_empty(vq->dev, vq))
>> > + cpu_relax();
> Can you use cpu_relax_lowlatency (which should be the same as cpu_relax for
> almost
> everybody but s390? cpu_relax (without low latency might give up the time
> slice
> when running under another hypervisor (like LPAR on s390), which might not be
> what
> we want here.
Ok, will do this in next version.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V3 3/3] vhost_net: basic polling support
On 02/28/2016 10:09 PM, Michael S. Tsirkin wrote:
> On Fri, Feb 26, 2016 at 04:42:44PM +0800, Jason Wang wrote:
>> > This patch tries to poll for new added tx buffer or socket receive
>> > queue for a while at the end of tx/rx processing. The maximum time
>> > spent on polling were specified through a new kind of vring ioctl.
>> >
>> > Signed-off-by: Jason Wang
> Looks good overall, but I still see one problem.
>
>> > ---
>> > drivers/vhost/net.c| 79
>> > +++---
>> > drivers/vhost/vhost.c | 14
>> > drivers/vhost/vhost.h | 1 +
>> > include/uapi/linux/vhost.h | 6
>> > 4 files changed, 95 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> > index 9eda69e..c91af93 100644
>> > --- a/drivers/vhost/net.c
>> > +++ b/drivers/vhost/net.c
>> > @@ -287,6 +287,44 @@ static void vhost_zerocopy_callback(struct ubuf_info
>> > *ubuf, bool success)
>> >rcu_read_unlock_bh();
>> > }
>> >
>> > +static inline unsigned long busy_clock(void)
>> > +{
>> > + return local_clock() >> 10;
>> > +}
>> > +
>> > +static bool vhost_can_busy_poll(struct vhost_dev *dev,
>> > + unsigned long endtime)
>> > +{
>> > + return likely(!need_resched()) &&
>> > + likely(!time_after(busy_clock(), endtime)) &&
>> > + likely(!signal_pending(current)) &&
>> > + !vhost_has_work(dev) &&
>> > + single_task_running();
> So I find it quite unfortunate that this still uses single_task_running.
> This means that for example a SCHED_IDLE task will prevent polling from
> becoming active, and that seems like a bug, or at least
> an undocumented feature :).
Yes, it may need more thoughts.
>
> Unfortunately this logic affects the behaviour as observed
> by userspace, so we can't merge it like this and tune
> afterwards, since otherwise mangement tools will start
> depending on this logic.
>
>
How about remove single_task_running() first here and optimize on top?
We probably need something like this to handle overcommitment.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V3 3/3] vhost_net: basic polling support
On 02/26/2016 09:42 AM, Jason Wang wrote:
> This patch tries to poll for new added tx buffer or socket receive
> queue for a while at the end of tx/rx processing. The maximum time
> spent on polling were specified through a new kind of vring ioctl.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/net.c| 79
> +++---
> drivers/vhost/vhost.c | 14
> drivers/vhost/vhost.h | 1 +
> include/uapi/linux/vhost.h | 6
> 4 files changed, 95 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 9eda69e..c91af93 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -287,6 +287,44 @@ static void vhost_zerocopy_callback(struct ubuf_info
> *ubuf, bool success)
> rcu_read_unlock_bh();
> }
>
> +static inline unsigned long busy_clock(void)
> +{
> + return local_clock() >> 10;
> +}
> +
> +static bool vhost_can_busy_poll(struct vhost_dev *dev,
> + unsigned long endtime)
> +{
> + return likely(!need_resched()) &&
> +likely(!time_after(busy_clock(), endtime)) &&
> +likely(!signal_pending(current)) &&
> +!vhost_has_work(dev) &&
> +single_task_running();
> +}
> +
> +static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
> + struct vhost_virtqueue *vq,
> + struct iovec iov[], unsigned int iov_size,
> + unsigned int *out_num, unsigned int *in_num)
> +{
> + unsigned long uninitialized_var(endtime);
> + int r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
> + out_num, in_num, NULL, NULL);
> +
> + if (r == vq->num && vq->busyloop_timeout) {
> + preempt_disable();
> + endtime = busy_clock() + vq->busyloop_timeout;
> + while (vhost_can_busy_poll(vq->dev, endtime) &&
> +vhost_vq_avail_empty(vq->dev, vq))
> + cpu_relax();
Can you use cpu_relax_lowlatency (which should be the same as cpu_relax for
almost
everybody but s390? cpu_relax (without low latency might give up the time slice
when running under another hypervisor (like LPAR on s390), which might not be
what
we want here.
[...]
> +static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
> +{
> + struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
> + struct vhost_virtqueue *vq = &nvq->vq;
> + unsigned long uninitialized_var(endtime);
> + int len = peek_head_len(sk);
> +
> + if (!len && vq->busyloop_timeout) {
> + /* Both tx vq and rx socket were polled here */
> + mutex_lock(&vq->mutex);
> + vhost_disable_notify(&net->dev, vq);
> +
> + preempt_disable();
> + endtime = busy_clock() + vq->busyloop_timeout;
> +
> + while (vhost_can_busy_poll(&net->dev, endtime) &&
> +skb_queue_empty(&sk->sk_receive_queue) &&
> +vhost_vq_avail_empty(&net->dev, vq))
> + cpu_relax();
here as well.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V3 3/3] vhost_net: basic polling support
On Fri, Feb 26, 2016 at 04:42:44PM +0800, Jason Wang wrote:
> This patch tries to poll for new added tx buffer or socket receive
> queue for a while at the end of tx/rx processing. The maximum time
> spent on polling were specified through a new kind of vring ioctl.
>
> Signed-off-by: Jason Wang
Looks good overall, but I still see one problem.
> ---
> drivers/vhost/net.c| 79
> +++---
> drivers/vhost/vhost.c | 14
> drivers/vhost/vhost.h | 1 +
> include/uapi/linux/vhost.h | 6
> 4 files changed, 95 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 9eda69e..c91af93 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -287,6 +287,44 @@ static void vhost_zerocopy_callback(struct ubuf_info
> *ubuf, bool success)
> rcu_read_unlock_bh();
> }
>
> +static inline unsigned long busy_clock(void)
> +{
> + return local_clock() >> 10;
> +}
> +
> +static bool vhost_can_busy_poll(struct vhost_dev *dev,
> + unsigned long endtime)
> +{
> + return likely(!need_resched()) &&
> +likely(!time_after(busy_clock(), endtime)) &&
> +likely(!signal_pending(current)) &&
> +!vhost_has_work(dev) &&
> +single_task_running();
So I find it quite unfortunate that this still uses single_task_running.
This means that for example a SCHED_IDLE task will prevent polling from
becoming active, and that seems like a bug, or at least
an undocumented feature :).
Unfortunately this logic affects the behaviour as observed
by userspace, so we can't merge it like this and tune
afterwards, since otherwise mangement tools will start
depending on this logic.
> +}
> +
> +static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
> + struct vhost_virtqueue *vq,
> + struct iovec iov[], unsigned int iov_size,
> + unsigned int *out_num, unsigned int *in_num)
> +{
> + unsigned long uninitialized_var(endtime);
> + int r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
> + out_num, in_num, NULL, NULL);
> +
> + if (r == vq->num && vq->busyloop_timeout) {
> + preempt_disable();
> + endtime = busy_clock() + vq->busyloop_timeout;
> + while (vhost_can_busy_poll(vq->dev, endtime) &&
> +vhost_vq_avail_empty(vq->dev, vq))
> + cpu_relax();
> + preempt_enable();
> + r = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
> + out_num, in_num, NULL, NULL);
> + }
> +
> + return r;
> +}
> +
> /* 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)
> @@ -331,10 +369,9 @@ static void handle_tx(struct vhost_net *net)
> % UIO_MAXIOV == nvq->done_idx))
> break;
>
> - head = vhost_get_vq_desc(vq, vq->iov,
> - ARRAY_SIZE(vq->iov),
> - &out, &in,
> - NULL, NULL);
> + head = vhost_net_tx_get_vq_desc(net, vq, vq->iov,
> + ARRAY_SIZE(vq->iov),
> + &out, &in);
> /* On error, stop handling until the next kick. */
> if (unlikely(head < 0))
> break;
> @@ -435,6 +472,38 @@ static int peek_head_len(struct sock *sk)
> return len;
> }
>
> +static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
> +{
> + struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
> + struct vhost_virtqueue *vq = &nvq->vq;
> + unsigned long uninitialized_var(endtime);
> + int len = peek_head_len(sk);
> +
> + if (!len && vq->busyloop_timeout) {
> + /* Both tx vq and rx socket were polled here */
> + mutex_lock(&vq->mutex);
> + vhost_disable_notify(&net->dev, vq);
> +
> + preempt_disable();
> + endtime = busy_clock() + vq->busyloop_timeout;
> +
> + while (vhost_can_busy_poll(&net->dev, endtime) &&
> +skb_queue_empty(&sk->sk_receive_queue) &&
> +vhost_vq_avail_empty(&net->dev, vq))
> + cpu_relax();
> +
> + preempt_enable();
> +
> + if (vhost_enable_notify(&net->dev, vq))
> + vhost_poll_queue(&vq->poll);
> + mutex_unlock(&vq->mutex);
> +
> + len = peek_head_len(sk);
> + }
> +
> + return len;
> +}
> +
> /* This is a multi-buffer version of vhost_get_desc, that works if
> * vq has read descriptors only.
> * @vq
Call For Papers - CISTI 2016 Workshops - Deadline March 15
- CISTI'2016 Workshops Gran Canaria, Canary Islands, Spain June 15 - 18, 2016 http://www.aisti.eu/cisti2016/index.php/es/xpto - Introduction We are pleased to invite the academic and business community to submit their papers to the CISTI'2016 Workshops (11th Iberian Conference on Information Systems and Technologies), to be held in Gran Canaria, Canary Islands, Spain, between the 15th and 18th of June 2016. Authors are encouraged to submit original scientific contributions such as state-of-art reviews and new research perspectives, groundbreaking ideas and/or architectures, solutions and/or applications for real problems, empirical and/or evaluation works, case studies, etc., in conformity with the themes and specific call-for paper of each Workshop (http://www.aisti.eu/cisti2016/index.php/es/xpto) CISTI 2016 Workshops CISTI will feature the following Workshops: - 3rd Workshop on Applied Statistics and Data Analysis using Computer Science (ASDACS) - 8th Workshop on Intelligent Systems and Applications (WISA) - 2nd Workshop on Gaming, Simulation and Play (WGSP) - 3rd Workshop on ICT for Auditing (WICTA) - 3rd Workshop on Computational Biomedical Image Processing and Analysis (WCBIPA) - Workshop on Quality Assessment and Systems in Health, Education and Services (QAS) - Workshop on Internet, Businesses, Societies and Social Web (INSWS) - Workshop on New Pedagogical Approaches with Technologies (NPAT) - Workshop on Judicial Informatics/Informática Júridica (InJu) - Workshop on Software Engineering for Scientific Applications / Ingeniería de Software para Aplicaciones Científicas (ISAC) - Workshop on Software Product Families/Familia de Productos de Software (FaProS) - Workshop on Business Management, Communication and Digital Social Network/Gestión de Empresa, Comunicación y Redes Sociales Digitales (WGECRSD) Paper Submission We invite prospective authors to submit their contributions, not yet published, reporting on either work under development or concluded projects about theoretical aspects or practical applications related to the topics of the workshop. Contributions can be submitted in one of two formats: Full papers - original, relevant and previously unpublished research results, related to any of the topics of the conference, with a maximum of 6 pages. Short papers - project reports, research in progress, with no more than 4 pages. Papers will be presented and discussed in time slots of 20 (full papers) or 15 minutes (short papers). The contributions can be written either in English, Portuguese or Spanish, and should be submitted in PDF format, through the conference webpage (https://easychair.org/conferences/?conf=cistiworkshops2016). All papers must follow the formatting rules of the Conference (http://www.aisti.eu/cisti2016/index.php/en/callfor-papers) with templates at: http://www.aisti.eu/cisti2015/templates.zip. Please note that, the contributions to be evaluated by the Scientific Committee should not include authors identification, e-mail or affiliation (blinded submission). --- Publication --- To ensure that the contribution (full paper or short paper) is published in the Proceedings, at least one of the authors must be fully registered, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended modifications must be addressed by the authors before they submit the final version. No more than one paper per registration will be published in the Conference Proceedings. Full papers will be published in both book and CD formats, with an ISBN. Short papers will be published in CD only, with an ISBN. Published full and short papers will be sent to EI, IEEE XPlore, INSPEC, ISI, SCOPUS and Google Scholar. Detailed and up-to-date information may be found at CISTI 2016 website:http://www.aisti.eu/cisti2016. --- Important Dates --- (please note that some Workshops have different deadlines) - Paper submission: March 15, 2016 - Author Notification: March 29, 2016 - Camera Ready: April 10, 2016 - Conference: June 15-18, 2016 We are counting on you. Please submit your contribution. CISTI 2016 Chairs http://www.aisti.eu/cisti2016/ ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V3 0/3] basic busy polling support for vhost_net
On Fri, Feb 26, 2016 at 11:45:02AM -0500, David Miller wrote: > From: Jason Wang > Date: Fri, 26 Feb 2016 16:42:41 +0800 > > > This series tries to add basic busy polling for vhost net. The idea is > > simple: at the end of tx/rx processing, busy polling for new tx added > > descriptor and rx receive socket for a while. The maximum number of > > time (in us) could be spent on busy polling was specified ioctl. > > I'm assuming this will go through Michael's tree. Definitely. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
