|
|
Subscribe / Log in / New account

1½ Topics: realtime throttling and user-space adaptive spinning

1½ Topics: realtime throttling and user-space adaptive spinning

Posted May 14, 2023 5:39 UTC (Sun) by xecycle (subscriber, #140261)
In reply to: 1½ Topics: realtime throttling and user-space adaptive spinning by quotemstr
Parent article: 1½ Topics: realtime throttling and user-space adaptive spinning

Also interested in this part. Correct me if I'm wrong, is it that what people have proposed can be simply taken as, "hey kernel, please set this flag if you preempt me"? Then I think it may benefit another use case, the flat-combining technique. Maybe, instead of telling another thread to sleep, it could take over work left by the original lock owner. I hope the final solution can accommodate this.


to post comments

1½ Topics: realtime throttling and user-space adaptive spinning

Posted May 15, 2023 2:48 UTC (Mon) by nevets (subscriber, #11875) [Link] (1 responses)

If this is implemented, then that use case is possible. But I'm not sure of what would use that use case.

1½ Topics: realtime throttling and user-space adaptive spinning

Posted May 15, 2023 15:38 UTC (Mon) by atnot (subscriber, #124910) [Link]

The main place I've seen things of this sort is garbage collection. If you have some shared data structure that allocates, *someone* needs to do the cleanup and usually you'd really prefer if that wasn't you or a thread you're waiting on. This leads to all kinds of complex heuristics and hints. If you can just pass the broom on to whoever wants to touch the data next, that has the potential to decrease tail latencies a lot.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds