>> Is there some reason you don't use the simpler singly-linked list
>> construction with the tail being a pointer to a pointer:
> Sure, that would also work.
It's just a convenient simplification, already used in struct hlist_node.
>> +/*
>> + * Queue a task for later wake-up by wake_up_q(). I
On Mon, 2015-04-20 at 14:24 -0400, George Spelvin wrote:
> +struct wake_q_head {
> + struct wake_q_node *first;
> + struct wake_q_node *last;
> +};
> +
> +#define WAKE_Q_TAIL ((struct wake_q_node *) 0x01)
> +
> +#define WAKE_Q(name) \
> + struct wake_q_he
+struct wake_q_head {
+ struct wake_q_node *first;
+ struct wake_q_node *last;
+};
+
+#define WAKE_Q_TAIL ((struct wake_q_node *) 0x01)
+
+#define WAKE_Q(name) \
+ struct wake_q_head name = { WAKE_Q_TAIL, WAKE_Q_TAIL }
Is there some reason you do
On Sun, Apr 19, 2015 at 12:17:39PM -0700, Davidlohr Bueso wrote:
> +void wake_q_add(struct wake_q_head *head, struct task_struct *task)
> +{
> + struct wake_q_node *node = &task->wake_q;
> +
> + /*
> + * Atomically grab the task, if ->wake_q is !nil already it means
> + * its alre
From: Peter Zijlstra
This is useful for locking primitives that can effect multiple
wakeups per operation and want to avoid lock internal lock contention
by delaying the wakeups until we've released the lock internal locks.
Alternatively it can be used to avoid issuing multiple wakeups, and
thus
5 matches
Mail list logo
