Proposed usage case is mutexes deciding whether to spin for a while or immediately futex_wait.
-
-
-
If there are tasks waiting, spinning for a mutex is wasting cpu time during which something else could be running.
-
yielding while spinning? I think that's not a good idea.
-
No. Immediately using futex_wait instead of spinning for a while first.
-
Spinning first is almost-pure-win (modulo slight electricity cost) if nothing else is waiting to run, pure-loss if something is.
-
not pure loss. Scheduling decides if it's a loss. What's the compelling argument for messing with scheduling?
-
I think you're misunderstanding. Every spin for which you don't get the lock is wasted cpu cycles. Scheduler is irrelevant.
-
If there was nothing else that wanted to use those cycles, no big deal. But if there was, you've incurred a cost.
- 3 more replies
New conversation -
-
-
Alternate idea with different abstraction: VDSO version of futex_wait that spins in userspace iff kernel thinks that's appropriate.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
@sergeybratus you could just resurrect Irix and all the per-CPU tools we had back then (e.g. "runon" to pin to a CPU). -
Arguably, OSes are intricate cocktails of features--the mix being more important than the ingredients :)
-
one word: MULTICS :p
-
I was once told that every systems paper idea has been already published in the IBM Systems Journal :)
-
and all ITsec is contained in Karger74…
-
Tweet unavailable
-
So, we can play "if you knew you'd end up on an uninhabited island, which papers you'd take along?" :)
-
between the three of us? Can I just bring
@daniel_bilar as a "big book"? - 1 more reply
New conversation -
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.