search for: need_resch

Amos Kong <akong at redhat.com> writes: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. I don't understand this explanation? I'd expect the sysfs process to be woken by the mutex_unlock(). If we're really high priority (vs. the sysfs process) then I can see why we'd ne...

Amos Kong <akong at redhat.com> writes: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. I don't understand this explanation? I'd expect the sysfs process to be woken by the mutex_unlock(). If we're really high priority (vs. the sysfs process) then I can see why we'd ne...

...ites: > > > When I check hwrng attributes in sysfs, cat process always gets > > > stuck if guest has only 1 vcpu and uses a slow rng backend. > > > > > > Currently we check if there is any tasks waiting to be run on > > > current cpu in rng_dev_read() by need_resched(). But need_resched() > > > doesn't work because rng_dev_read() is executing in user context. > > > > I don't understand this explanation? I'd expect the sysfs process to be > > woken by the mutex_unlock(). > > But actually sysfs process's not w...

...ites: > > > When I check hwrng attributes in sysfs, cat process always gets > > > stuck if guest has only 1 vcpu and uses a slow rng backend. > > > > > > Currently we check if there is any tasks waiting to be run on > > > current cpu in rng_dev_read() by need_resched(). But need_resched() > > > doesn't work because rng_dev_read() is executing in user context. > > > > I don't understand this explanation? I'd expect the sysfs process to be > > woken by the mutex_unlock(). > > But actually sysfs process's not w...

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

On (Wed) 10 Sep 2014 [17:07:07], Amos Kong wrote: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. > > This patch removed need_resched() and increase delay to 10 jiffies, > then other tasks can have chance to execute protected code. > Delaying 1 jiffy also works, but 10 jiffies is safe...

On (Wed) 10 Sep 2014 [17:07:07], Amos Kong wrote: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. > > This patch removed need_resched() and increase delay to 10 jiffies, > then other tasks can have chance to execute protected code. > Delaying 1 jiffy also works, but 10 jiffies is safe...

...ns(-) diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c index 79d2d76..4f00b0c 100644 --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -236,7 +236,13 @@ bool mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner) */ barrier(); - if (!owner->on_cpu || need_resched()) { + /* + * Use vcpu_is_preempted to detech lock holder preemption issue + * and break. vcpu_is_preempted is a macro defined by false if + * arch does not support vcpu preempted check, + */ + if (!owner->on_cpu || need_resched() || + vcpu_is_preempted(task_cpu(owner))) { ret...

...ore.c > index aa30a25..fa69020 100644 > --- a/drivers/char/hw_random/core.c > +++ b/drivers/char/hw_random/core.c > @@ -194,6 +194,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > } > > mutex_unlock(&rng_mutex); > + udelay(100); We have a need_resched() right below. Why doesn't that work? > if (need_resched()) > schedule_timeout_interruptible(1); > @@ -233,10 +234,10 @@ static ssize_t hwrng_attr_current_store(struct device *dev, > int err; > struct hwrng *rng; The following hunk doesn't work: > + err =...

...ore.c > index aa30a25..fa69020 100644 > --- a/drivers/char/hw_random/core.c > +++ b/drivers/char/hw_random/core.c > @@ -194,6 +194,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > } > > mutex_unlock(&rng_mutex); > + udelay(100); We have a need_resched() right below. Why doesn't that work? > if (need_resched()) > schedule_timeout_interruptible(1); > @@ -233,10 +234,10 @@ static ssize_t hwrng_attr_current_store(struct device *dev, > int err; > struct hwrng *rng; The following hunk doesn't work: > + err =...

...kong at redhat.com> writes: > > When I check hwrng attributes in sysfs, cat process always gets > > stuck if guest has only 1 vcpu and uses a slow rng backend. > > > > Currently we check if there is any tasks waiting to be run on > > current cpu in rng_dev_read() by need_resched(). But need_resched() > > doesn't work because rng_dev_read() is executing in user context. > > I don't understand this explanation? I'd expect the sysfs process to be > woken by the mutex_unlock(). But actually sysfs process's not woken always, this is they the...

Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the committers which slows everybody out. To address thi...

..._preempted is a macro defined by arch/false. This is standard protocol in the kernel. Same goes for all locks you change with this. Thanks, Davidlohr > * vcpu_is_preempted is a macro defined by false if >+ * arch does not support vcpu preempted check, > */ >- if (need_resched()) >+ if (need_resched() || vcpu_is_preempted(node_cpu(node->prev))) > goto unqueue; > > cpu_relax_lowlatency(); >-- >2.4.11 >

..._preempted is a macro defined by arch/false. This is standard protocol in the kernel. Same goes for all locks you change with this. Thanks, Davidlohr > * vcpu_is_preempted is a macro defined by false if >+ * arch does not support vcpu preempted check, > */ >- if (need_resched()) >+ if (need_resched() || vcpu_is_preempted(node_cpu(node->prev))) > goto unqueue; > > cpu_relax_lowlatency(); >-- >2.4.11 >

When I check hwrng attributes in sysfs, cat process always gets stuck if guest has only 1 vcpu and uses a slow rng backend. Currently we check if there is any tasks waiting to be run on current cpu in rng_dev_read() by need_resched(). But need_resched() doesn't work because rng_dev_read() is executing in user context. This patch removed need_resched() and increase delay to 10 jiffies, then other tasks can have chance to execute protected code. Delaying 1 jiffy also works, but 10 jiffies is safer. Signed-off-by: Amos K...

change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc, and add config. remove dedicated macro. add one patch to drop overload of rwsem_spin_on_owner and mutex_spin_on_owner. add more comments thanks boqun and Peter's suggestion. This patch set aims to fix lock holder preemption

change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc, and add config. remove dedicated macro. add one patch to drop overload of rwsem_spin_on_owner and mutex_spin_on_owner. add more comments thanks boqun and Peter's suggestion. This patch set aims to fix lock holder preemption

...> --- a/drivers/char/hw_random/core.c > > +++ b/drivers/char/hw_random/core.c > > @@ -194,6 +194,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > > } > > > > mutex_unlock(&rng_mutex); > > + udelay(100); > > We have a need_resched() right below. Why doesn't that work? need_resched() is giving chance for userspace to > > if (need_resched()) It never success in my debugging. If we remove this check and always call schedule_timeout_interruptible(1), problem also disappears. diff --git a/drivers/char/hw_ra...

...10,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev, >> struct cpuidle_driver *drv, >> ??????????????? target_state = &drv->states[index]; >> ??????? } >> >> +#ifdef CONFIG_PARAVIRT >> +?????? paravirt_idle_poll(); >> + >> +?????? if (need_resched()) >> +?????????????? return -EBUSY; >> +#endif > That's just plain wrong. We don't want to see any of this PARAVIRT crap in > anything outside the architecture/hypervisor interfacing code which really > needs it. > > The problem can and must be solved at the ge...