On Tue, Jun 3, 2014 at 6:28 AM, Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote: > Possibly stupid question: Is it true that any given task can only be > using one wait_queue_t at a time?
Nope. Being on multiple different wait-queues is actually very common. The obvious case is select/poll, but there are others. The more subtle ones involve being on a wait-queue while doing something that can cause nested waiting (iow, it's technically not wrong to be on a wait-queue and then do a user space access, which obviously can end up doing IO). That said, the case of a single wait-queue entry is another common case, and it wouldn't necessarily be wrong to have one pre-initialized wait queue entry in the task structure for that special case, for when you know that there is no possible nesting. And even if it *does* nest, if it's the "leaf" entry it could be used for that innermost nesting without worrying about other wait queue users (who use stack allocations or actual explicit allocations like poll). So it might certainly be worth looking at. In fact, it might be worth it having multiple per-thread entries, so that we could get rid of the special on-stack allocation for poll too (and making one of them special and not available to poll, to handle the "leaf waiter" case). So it's not necessarily a bad idea at all, even if the general case requires more than one (or a few) static per-thread allocations. Anybody want to try to code it up? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/