Displaying 5 results from an estimated 5 matches for "get_pending".
2023 May 22
1
[PATCH 1/3] signal: Don't always put SIGKILL in shared_pending
When get_pending detects the task has been marked to be killed we try to
clean up the SIGKLL by doing a sigdelset and recalc_sigpending, but we
still leave it in shared_pending. If the signal is being short circuit
delivered there is no need to put in shared_pending so this adds a check
in complete_signal.
This pa...
2023 May 22
3
[PATCH 0/3] vhost: Fix freezer/ps regressions
The following patches made over Linus's tree fix the 2 bugs:
1. vhost worker task shows up as a process forked from the parent
that did VHOST_SET_OWNER ioctl instead of a process under root/kthreadd.
This was causing breaking scripts.
2. vhost_tasks didn't disable or add support for freeze requests.
The following patches fix these issues by making the vhost_task task
a thread under the
2014 May 21
0
[RFC 08/07] qspinlock: integrate pending bit into queue
...is used here because the get_qlock()
- * function below may not be a full memory barrier.
- *
- * *,x,y -> *,0,0
+ * We are now waiting for the pending bit to get cleared.
*/
- while ((val = smp_load_acquire(&lock->val.counter))
- & _Q_LOCKED_PENDING_MASK)
+ // make a get_pending(lock, &val) helper
+ while ((val = smp_load_acquire(&lock->val.counter)) & _Q_PENDING_MASK)
+ // would longer body ease cacheline contention?
+ // would it be better to use monitor/mwait instead?
+ // (we can tolerate some delay because we aren't pending ...)
arch_mutex_cpu...
2014 May 14
2
[PATCH v10 03/19] qspinlock: Add pending bit
2014-05-14 19:00+0200, Peter Zijlstra:
> On Wed, May 14, 2014 at 06:51:24PM +0200, Radim Kr?m?? wrote:
> > Ok.
> > I've seen merit in pvqspinlock even with slightly slower first-waiter,
> > so I would have happily sacrificed those horrible branches.
> > (I prefer elegant to optimized code, but I can see why we want to be
> > strictly better than ticketlock.)
2014 May 14
2
[PATCH v10 03/19] qspinlock: Add pending bit
2014-05-14 19:00+0200, Peter Zijlstra:
> On Wed, May 14, 2014 at 06:51:24PM +0200, Radim Kr?m?? wrote:
> > Ok.
> > I've seen merit in pvqspinlock even with slightly slower first-waiter,
> > so I would have happily sacrificed those horrible branches.
> > (I prefer elegant to optimized code, but I can see why we want to be
> > strictly better than ticketlock.)