Searched refs:woke (Results 1 – 7 of 7) sorted by relevance
| /linux-6.12.1/samples/bpf/ |
| D | offwaketime.bpf.c | 67 struct wokeby_t woke; in waker() local
69 bpf_get_current_comm(&woke.name, sizeof(woke.name)); in waker()
70 woke.ret = bpf_get_stackid(ctx, &stackmap, STACKID_FLAGS); in waker()
72 bpf_map_update_elem(&wokeby, &pid, &woke, BPF_ANY); in waker()
78 struct wokeby_t *woke; in update_counts() local
87 woke = bpf_map_lookup_elem(&wokeby, &pid); in update_counts()
88 if (woke) { in update_counts()
89 key.wret = woke->ret; in update_counts()
90 __builtin_memcpy(&key.waker, woke->name, sizeof(key.waker)); in update_counts()
|
| /linux-6.12.1/Documentation/admin-guide/pm/ |
| D | suspend-flows.rst | 114 interrupt that woke up one of them comes from an IRQ that has been armed for
131 by another CPU that woke up earlier) and the scheduler tick on that CPU is
|
| /linux-6.12.1/Documentation/driver-api/usb/ |
| D | persist.rst | 35 system woke up, who cares? It'll still work the same when you type on
|
| /linux-6.12.1/Documentation/driver-api/media/drivers/ |
| D | zoran.rst | 474 I woke up, and can't go to sleep again. I'll kill some time explaining why
|
| /linux-6.12.1/Documentation/locking/ |
| D | rt-mutex-design.rst | 534 in the slow path too. If a waiter of a mutex woke up because of a signal
|
| /linux-6.12.1/Documentation/RCU/Design/Data-Structures/ |
| D | Data-Structures.rst | 764 high-priority process just woke up on this CPU, then the remaining
|
| /linux-6.12.1/Documentation/trace/ |
| D | ftrace.rst | 2019 just 15 microseconds from the time it woke up, to the time it
|