lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 25 Nov 2008 13:19:54 -0800 (PST) From: Davide Libenzi <davidel@...ilserver.org> To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> cc: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>, Ingo Molnar <mingo@...e.hu>, ltt-dev@...ts.casi.polymtl.ca, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, William Lee Irwin III <wli@...omorphy.com> Subject: Re: [PATCH] Poll : introduce poll_wait_exclusive() new function On Tue, 25 Nov 2008, KOSAKI Motohiro wrote: > > patch againt: tip/tracing/marker > > ========== > Currently, wake_up() function behavior depend on the way of > wait queue adding function. > > > wake_up() wake_up_all() > --------------------------------------------------------------- > add_wait_queue() wake up all wake up all > add_wait_queue_exclusive() wake up one task wake up all > > > Unforunately, poll_wait() always use add_wait_queue(). > it means there is no way that wake up only one process in polled processes. > wake_up() also wake up all sleeping processes, not 1 process. > > > Mathieu Desnoyers explained it cause following problem to LTTng. > > In LTTng, all lttd readers are polling all the available debugfs files > for data. This is principally because the number of reader threads is > user-defined and there are typical workloads where a single CPU is > producing most of the tracing data and all other CPUs are idle, > available to consume data. It therefore makes sense not to tie those > threads to specific buffers. However, when the number of threads grows, > we face a "thundering herd" problem where many threads can be woken up > and put back to sleep, leaving only a single thread doing useful work. Why do you need to have so many threads banging a single device/file? Have one (or any other very little number) puller thread(s), that activates with chucks of pulled data the other processing threads. That way there's no need for a new wakeup abstraction. - Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists