search for: cond_resch

...; rcu: INFO: rcu_sched self-detected stall on CPU. > > Fixes: 986a4f4d452d ("virtio_net: multiqueue support") > Signed-off-by: Wenliang Wang <wangwenliang.1995 at bytedance.com> > --- > v2: > -add need_resched check. > -apply same logic to sq. > v3: > -use cond_resched instead. > v4: > -add fixes tag > --- > drivers/net/virtio_net.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 8d8038538fc4..a12ae26db0e2 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers...

On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: > On 7/20/23 1:38 AM, Jason Wang wrote: > > > > Adding cond_resched() to the command waiting loop for a better > > co-operation with the scheduler. This allows to give CPU a breath to > > run other task(workqueue) instead of busy looping when preemption is > > not allowed on a device whose CVQ might be slow. > > > > Signed-off-by: J...

On 7/20/23 23:02, Michael S. Tsirkin wrote: > On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: >> On 7/20/23 1:38 AM, Jason Wang wrote: >>> >>> Adding cond_resched() to the command waiting loop for a better >>> co-operation with the scheduler. This allows to give CPU a breath to >>> run other task(workqueue) instead of busy looping when preemption is >>> not allowed on a device whose CVQ might be slow. >>> >>> Si...

...n Fri, Jul 21, 2023 at 04:37:00PM +0200, Maxime Coquelin wrote: > > > On 7/20/23 23:02, Michael S. Tsirkin wrote: > > On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: > > > On 7/20/23 1:38 AM, Jason Wang wrote: > > > > > > > > Adding cond_resched() to the command waiting loop for a better > > > > co-operation with the scheduler. This allows to give CPU a breath to > > > > run other task(workqueue) instead of busy looping when preemption is > > > > not allowed on a device whose CVQ might be slow. > &g...

...023 at 04:37:00PM +0200, Maxime Coquelin wrote: >> >> >> On 7/20/23 23:02, Michael S. Tsirkin wrote: >>> On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: >>>> On 7/20/23 1:38 AM, Jason Wang wrote: >>>>> >>>>> Adding cond_resched() to the command waiting loop for a better >>>>> co-operation with the scheduler. This allows to give CPU a breath to >>>>> run other task(workqueue) instead of busy looping when preemption is >>>>> not allowed on a device whose CVQ might be slow. >...

...gt; > > > > > > > On 7/20/23 23:02, Michael S. Tsirkin wrote: > > > > On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: > > > > > On 7/20/23 1:38 AM, Jason Wang wrote: > > > > > > > > > > > > Adding cond_resched() to the command waiting loop for a better > > > > > > co-operation with the scheduler. This allows to give CPU a breath to > > > > > > run other task(workqueue) instead of busy looping when preemption is > > > > > > not allowed on a device wh...

...CPU. > > > > Fixes: 986a4f4d452d ("virtio_net: multiqueue support") > > Signed-off-by: Wenliang Wang <wangwenliang.1995 at bytedance.com> > > --- > > v2: > > -add need_resched check. > > -apply same logic to sq. > > v3: > > -use cond_resched instead. > > v4: > > -add fixes tag > > --- > > drivers/net/virtio_net.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index 8d8038538fc4..a12ae26db0e2 100644 > > ---...

On Thu, Jul 27, 2023 at 04:59:33PM +0800, Jason Wang wrote: > > They really shouldn't - any NIC that takes forever to > > program will create issues in the networking stack. > > Unfortunately, it's not rare as the device/cvq could be implemented > via firmware or software. Currently that mean one either has sane firmware with a scheduler that can meet deadlines, or

...unction itself might sleep so it cannot be called from atomic > > > + * contexts. > > I don't see how walk_free_mem_block() can sleep. > > OK, it would be better to remove this sentence for the current version. But > I think we could probably keep it if we decide to add cond_resched() below. The point of this sentence was to make any user aware that the function might sleep from the very begining rather than chase existing callers when we need to add cond_resched or sleep for any other reason. So I would rather keep it. -- Michal Hocko SUSE Labs

...unction itself might sleep so it cannot be called from atomic > > > + * contexts. > > I don't see how walk_free_mem_block() can sleep. > > OK, it would be better to remove this sentence for the current version. But > I think we could probably keep it if we decide to add cond_resched() below. The point of this sentence was to make any user aware that the function might sleep from the very begining rather than chase existing callers when we need to add cond_resched or sleep for any other reason. So I would rather keep it. -- Michal Hocko SUSE Labs

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need first convert rx mode handling to a workqueue. Please review. Thanks Changes since V2: - Don't use interrupt but cond_resched() Changes since V1: - use RTNL...

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need first convert rx mode handling to a workqueue. Note that, this doesn't try to solve the case that a malicous device may block networking stack (RTNL) or break fr...

...et: multiqueue support") > Signed-off-by: Wenliang Wang <wangwenliang.1995 at bytedance.com> Acked-by: Michael S. Tsirkin <mst at redhat.com> Probably a good idea for stable, too. > --- > v2: > -add need_resched check. > -apply same logic to sq. > v3: > -use cond_resched instead. > v4: > -add fixes tag > --- > drivers/net/virtio_net.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 8d8038538fc4..a12ae26db0e2 100644 > --- a/drivers/net/virtio_net.c > +++ b/driver...

...(opaque, zone, > + order, mt, > + report_pfn_range); > + if (ret) > + return ret; > + } > + } > + } > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(walk_free_mem_block); This looks like it could take a long time. Will we end up needing to add cond_resched() in there somewhere? > static void zoneref_set_zone(struct zone *zone, struct zoneref *zoneref) > { > zoneref->zone = zone; > -- > 2.7.4

...(opaque, zone, > + order, mt, > + report_pfn_range); > + if (ret) > + return ret; > + } > + } > + } > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(walk_free_mem_block); This looks like it could take a long time. Will we end up needing to add cond_resched() in there somewhere? > static void zoneref_set_zone(struct zone *zone, struct zoneref *zoneref) > { > zoneref->zone = zone; > -- > 2.7.4

Hi, when creating a bigger (> 50 GB) HVM guest with maxmem > memory we get softlockups from time to time. kernel: [ 802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351] I tracked this down to the call of xc_domain_set_pod_target() and further p2m_pod_set_mem_target(). Unfortunately I can this check only with xen-4.2.2 as I don''t have a machine with enough memory for

...t; + * >> + * The function itself might sleep so it cannot be called from atomic >> + * contexts. > I don't see how walk_free_mem_block() can sleep. OK, it would be better to remove this sentence for the current version. But I think we could probably keep it if we decide to add cond_resched() below. > >> + * In general low orders tend to be very volatile and so it makes more >> + * sense to query larger ones first for various optimizations which like >> + * ballooning etc... This will reduce the overhead as well. >> + * >> + * Return 0 if it comple...

...p so it cannot be called from atomic > > > > + * contexts. > > > I don't see how walk_free_mem_block() can sleep. > > > > OK, it would be better to remove this sentence for the current version. But > > I think we could probably keep it if we decide to add cond_resched() below. > > The point of this sentence was to make any user aware that the function > might sleep from the very begining rather than chase existing callers > when we need to add cond_resched or sleep for any other reason. So I > would rather keep it. Let's say what it is the...

...nce.com> Net next is currently closed, but this patch could arguably land on the net tree - assuming Micheal agrees. In that case you should include a suitable Fixes tag - reposting a new version. > --- > v2: > -add need_resched check. > -apply same logic to sq. > v3: > -use cond_resched instead. > --- > drivers/net/virtio_net.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index ea1bd4bb326d..744bdc8a1abd 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -3...

...r *buf, > > > > > > > > > > mutex_unlock(&rng_mutex); > > > > > > > > > > - if (need_resched()) > > > > > - schedule_timeout_interruptible(1); > > > > > + schedule_timeout_interruptible(10); If cond_resched() does not work, it is a bug elsewehere. > Problem only occurred in non-smp guest, we can improve it to: > > if(!is_smp()) > schedule_timeout_interruptible(10); > > is_smp() is only available for arm arch, we need a gene...