search for: busypoll

...te: > On 2018?07?02? 10:45, Toshiaki Makita wrote: >> Hi Jason, >> >> On 2018/06/29 18:30, Jason Wang wrote: >>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >> ... >>>> To fix this, poll the work instead of enabling notification when >>>> busypoll is interrupted by something. IMHO signal_pending() and >>>> vhost_has_work() are kind of interruptions rather than signals to >>>> completely cancel the busypoll, so let's run busypoll after the >>>> necessary work is done. In order to avoid too long busyloop...

...te: > On 2018?07?02? 10:45, Toshiaki Makita wrote: >> Hi Jason, >> >> On 2018/06/29 18:30, Jason Wang wrote: >>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >> ... >>>> To fix this, poll the work instead of enabling notification when >>>> busypoll is interrupted by something. IMHO signal_pending() and >>>> vhost_has_work() are kind of interruptions rather than signals to >>>> completely cancel the busypoll, so let's run busypoll after the >>>> necessary work is done. In order to avoid too long busyloop...

...t;>>> Hi Jason, >>>> >>>> On 2018/06/29 18:30, Jason Wang wrote: >>>>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >>>> ... >>>>>> To fix this, poll the work instead of enabling notification when >>>>>> busypoll is interrupted by something. IMHO signal_pending() and >>>>>> vhost_has_work() are kind of interruptions rather than signals to >>>>>> completely cancel the busypoll, so let's run busypoll after the >>>>>> necessary work is done. In order to...

...t;>>> Hi Jason, >>>> >>>> On 2018/06/29 18:30, Jason Wang wrote: >>>>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >>>> ... >>>>>> To fix this, poll the work instead of enabling notification when >>>>>> busypoll is interrupted by something. IMHO signal_pending() and >>>>>> vhost_has_work() are kind of interruptions rather than signals to >>>>>> completely cancel the busypoll, so let's run busypoll after the >>>>>> necessary work is done. In order to...

...; >>>>>> On 2018/06/29 18:30, Jason Wang wrote: >>>>>>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >>>>>> ... >>>>>>>> To fix this, poll the work instead of enabling notification when >>>>>>>> busypoll is interrupted by something. IMHO signal_pending() and >>>>>>>> vhost_has_work() are kind of interruptions rather than signals to >>>>>>>> completely cancel the busypoll, so let's run busypoll after the >>>>>>>> necessary w...

Hi Jason, On 2018/06/29 18:30, Jason Wang wrote: > On 2018?06?29? 16:09, Toshiaki Makita wrote: ... >> To fix this, poll the work instead of enabling notification when >> busypoll is interrupted by something. IMHO signal_pending() and >> vhost_has_work() are kind of interruptions rather than signals to >> completely cancel the busypoll, so let's run busypoll after the >> necessary work is done. In order to avoid too long busyloop due to >> interru...

...5, Toshiaki Makita wrote: >>> Hi Jason, >>> >>> On 2018/06/29 18:30, Jason Wang wrote: >>>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >>> ... >>>>> To fix this, poll the work instead of enabling notification when >>>>> busypoll is interrupted by something. IMHO signal_pending() and >>>>> vhost_has_work() are kind of interruptions rather than signals to >>>>> completely cancel the busypoll, so let's run busypoll after the >>>>> necessary work is done. In order to avoid too l...

Hi Jason, On 2018/06/29 18:30, Jason Wang wrote: > On 2018?06?29? 16:09, Toshiaki Makita wrote: ... >> To fix this, poll the work instead of enabling notification when >> busypoll is interrupted by something. IMHO signal_pending() and >> vhost_has_work() are kind of interruptions rather than signals to >> completely cancel the busypoll, so let's run busypoll after the >> necessary work is done. In order to avoid too long busyloop due to >> interru...

...>>>>> >>>>> On 2018/06/29 18:30, Jason Wang wrote: >>>>>> On 2018?06?29? 16:09, Toshiaki Makita wrote: >>>>> ... >>>>>>> To fix this, poll the work instead of enabling notification when >>>>>>> busypoll is interrupted by something. IMHO signal_pending() and >>>>>>> vhost_has_work() are kind of interruptions rather than signals to >>>>>>> completely cancel the busypoll, so let's run busypoll after the >>>>>>> necessary work is done....

On 2018?07?02? 10:45, Toshiaki Makita wrote: > Hi Jason, > > On 2018/06/29 18:30, Jason Wang wrote: >> On 2018?06?29? 16:09, Toshiaki Makita wrote: > ... >>> To fix this, poll the work instead of enabling notification when >>> busypoll is interrupted by something. IMHO signal_pending() and >>> vhost_has_work() are kind of interruptions rather than signals to >>> completely cancel the busypoll, so let's run busypoll after the >>> necessary work is done. In order to avoid too long busyloop due to >...

On 2018?07?03? 15:31, Toshiaki Makita wrote: > We may run out of avail rx ring descriptor under heavy load but busypoll > did not detect it so busypoll may have exited prematurely. Avoid this by > checking rx ring full during busypoll. Actually, we're checking whether it was empty in fact? > > Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> > --- > drivers/vhost/net....

On 2018?07?03? 15:31, Toshiaki Makita wrote: > We may run out of avail rx ring descriptor under heavy load but busypoll > did not detect it so busypoll may have exited prematurely. Avoid this by > checking rx ring full during busypoll. Actually, we're checking whether it was empty in fact? > > Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> > --- > drivers/vhost/net....

Under heavy load vhost tx busypoll tend not to suppress vq kicks, which causes poor guest tx performance. The detailed scenario is described in commitlog of patch 2. Rx seems not to have that serious problem, but for consistency I made a similar change on rx to avoid rx wakeups (patch 3). Additionary patch 4 is to avoid rx kicks und...

Under heavy load vhost busypoll may run without suppressing notification. For example tx zerocopy callback can push tx work while handle_tx() is running, then busyloop exits due to vhost_has_work() condition and enables notification but immediately reenters handle_tx() because the pushed work was tx. In this case handle_tx() trie...

Under heavy load vhost busypoll may run without suppressing notification. For example tx zerocopy callback can push tx work while handle_tx() is running, then busyloop exits due to vhost_has_work() condition and enables notification but immediately reenters handle_tx() because the pushed work was tx. In this case handle_tx() trie...

On Fri, Jun 29, 2018 at 05:09:50PM +0900, Toshiaki Makita wrote: > Under heavy load vhost busypoll may run without suppressing > notification. For example tx zerocopy callback can push tx work while > handle_tx() is running, then busyloop exits due to vhost_has_work() > condition and enables notification but immediately reenters handle_tx() > because the pushed work was tx. In this c...

On 2018/07/02 11:41, Jason Wang wrote: > On 2018?06?30? 00:38, Michael S. Tsirkin wrote: >> On Fri, Jun 29, 2018 at 05:09:50PM +0900, Toshiaki Makita wrote: >>> Under heavy load vhost busypoll may run without suppressing >>> notification. For example tx zerocopy callback can push tx work while >>> handle_tx() is running, then busyloop exits due to vhost_has_work() >>> condition and enables notification but immediately reenters handle_tx() >>> because t...

We may run handle_rx() while rx work is queued. For example a packet can push the rx work during the window before handle_rx calls vhost_net_disable_vq(). In that case busypoll immediately exits due to vhost_has_work() condition and enables vq again. This can lead to another unnecessary rx wake-ups, so poll rx work instead of enabling the vq. Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp> --- drivers/vhost/net.c | 26 +++++++++++++++++++-------...

On 2018?06?30? 00:38, Michael S. Tsirkin wrote: > On Fri, Jun 29, 2018 at 05:09:50PM +0900, Toshiaki Makita wrote: >> Under heavy load vhost busypoll may run without suppressing >> notification. For example tx zerocopy callback can push tx work while >> handle_tx() is running, then busyloop exits due to vhost_has_work() >> condition and enables notification but immediately reenters handle_tx() >> because the pushed work w...

On 2018?06?30? 00:38, Michael S. Tsirkin wrote: > On Fri, Jun 29, 2018 at 05:09:50PM +0900, Toshiaki Makita wrote: >> Under heavy load vhost busypoll may run without suppressing >> notification. For example tx zerocopy callback can push tx work while >> handle_tx() is running, then busyloop exits due to vhost_has_work() >> condition and enables notification but immediately reenters handle_tx() >> because the pushed work w...