Home
last modified time | relevance | path

Searched refs:sleeper (Results 1 – 5 of 5) sorted by relevance

/linux-4.1.27/arch/mips/alchemy/common/
DMakefile9 setup.o sleeper.o dma.o dbdma.o vss.o irq.o usb.o
/linux-4.1.27/tools/perf/scripts/python/
Dsched-migration.py47 def __init__(self, sleeper): argument
48 self.sleeper = sleeper
51 return "%s gone to sleep" % thread_name(self.sleeper)
/linux-4.1.27/net/sunrpc/
Dcache.c579 struct thread_deferred_req sleeper; in cache_wait_req() local
580 struct cache_deferred_req *dreq = &sleeper.handle; in cache_wait_req()
582 sleeper.completion = COMPLETION_INITIALIZER_ONSTACK(sleeper.completion); in cache_wait_req()
589 &sleeper.completion, req->thread_wait) <= 0) { in cache_wait_req()
594 if (!hlist_unhashed(&sleeper.handle.hash)) { in cache_wait_req()
595 __unhash_deferred_req(&sleeper.handle); in cache_wait_req()
604 wait_for_completion(&sleeper.completion); in cache_wait_req()
/linux-4.1.27/ipc/
Dsem.c107 struct task_struct *sleeper; /* this process */ member
722 wake_up_process(q->sleeper); in wake_up_sem_queue_do()
1951 queue.sleeper = current; in SYSCALL_DEFINE4()
/linux-4.1.27/Documentation/
Dmemory-barriers.txt1963 Firstly, the sleeper normally follows something like this sequence of events:
2058 [!] Note that the memory barriers implied by the sleeper and the waker do _not_
2060 values after the sleeper has called set_current_state(). For instance, if the
2061 sleeper does:
2076 the sleeper as coming after the change to my_data. In such a circumstance, the
2078 separate data accesses. Thus the above sleeper ought to do: