diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and.md new file mode 100644 index 0000000..0863e60 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and.md @@ -0,0 +1,39 @@ +--- +title: "@NOTimothyLottes most futex impls i've seen check for that and early return before the syscall, but you likely already knew that" +type: archive +source: twitter +source_url: "https://x.com/BonbliStar/status/2065944487075975648" +author: "Bonbli ★" +handle: BonbliStar +post_id: "2065944487075975648" +date: 2026-06-13 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes most futex impls i've seen check for that and early return before the syscall, but you likely already knew that" +in_reply_to: "" +parent_post_id: "2065840191340707905" +--- + +## Source + +- URL: https://x.com/BonbliStar/status/2065944487075975648 +- Author: Bonbli ★ (@BonbliStar) +- Posted: 2026-06-13 23:48:43 + +## Branch + +**1/** + +@NOTimothyLottes most futex impls i've seen check for that and early return before the syscall, but you likely already knew that + +**2/** + +@BonbliStar Yes, the comment was more the point of designing for the worst case, the limit of possibly blocking calls that interact with the scheduling. + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops]] diff --git a/archive/threads/NOTimothyLottes/2026-06-13-the-glibc-implementation-would-do-that/index.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-NOTimothyLottes-the-glibc-implementation-would-do-that-i-bypass.md similarity index 78% rename from archive/threads/NOTimothyLottes/2026-06-13-the-glibc-implementation-would-do-that/index.md rename to archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-NOTimothyLottes-the-glibc-implementation-would-do-that-i-bypass.md index c05de20..b47f322 100644 --- a/archive/threads/NOTimothyLottes/2026-06-13-the-glibc-implementation-would-do-that/index.md +++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-NOTimothyLottes-the-glibc-implementation-would-do-that-i-bypass.md @@ -7,14 +7,15 @@ author: "NOTimothyLottes" handle: NOTimothyLottes post_id: "2065872197147578751" date: 2026-06-13 -archived: 2026-08-23 +archived: 2026-08-25 draft: false tags: - archive - twitter - NOTimothyLottes description: "@axelgneiting The glibc implementation would do that." -in_reply_to: "2065851939917906296" +in_reply_to: "" +parent_post_id: "2065851939917906296" --- ## Source @@ -23,10 +24,14 @@ in_reply_to: "2065851939917906296" - Author: NOTimothyLottes (@NOTimothyLottes) - Posted: 2026-06-13 19:01:28 -## Thread +## Branch **1/** @axelgneiting The glibc implementation would do that. I bypass libc and just do it manually with perf_event_open syscall and mmap. -![](https://pbs.twimg.com/media/HKtzz5RXcAA6CIX?format=jpg&name=orig) \ No newline at end of file +![](https://pbs.twimg.com/media/HKtzz5RXcAA6CIX?format=jpg&name=orig) + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops]] diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm.md new file mode 100644 index 0000000..f763bec --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm.md @@ -0,0 +1,41 @@ +--- +title: "@NOTimothyLottes nanosleep(0) will sleep for the timer slack" +type: archive +source: twitter +source_url: "https://x.com/raggi/status/2065865513608307103" +author: "James Tucker" +handle: raggi +post_id: "2065865513608307103" +date: 2026-06-13 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes nanosleep(0) will sleep for the timer slack" +in_reply_to: "" +parent_post_id: "2065840191340707905" +--- + +## Source + +- URL: https://x.com/raggi/status/2065865513608307103 +- Author: James Tucker (@raggi) +- Posted: 2026-06-13 18:34:55 + +## Branch + +**1/** + +@NOTimothyLottes nanosleep(0) will sleep for the timer slack + +_mm_pause() if you want to avoid a context switch and keep your scheduler quantum + +**2/** + +@raggi I do that via inline asm to save power. This was more a comment on the cost of actually using the futex system call, need to be careful about the call frequency + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops]] diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates.md new file mode 100644 index 0000000..2db5271 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates.md @@ -0,0 +1,47 @@ +--- +title: "@NOTimothyLottes Seems like people trying to push high frame rates would be perfectly fine with just busy spinning at that point" +type: archive +source: twitter +source_url: "https://x.com/rflaherty71/status/2065859701909459406" +author: "Ryan Flaherty" +handle: rflaherty71 +post_id: "2065859701909459406" +date: 2026-06-13 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "@NOTimothyLottes Seems like people trying to push high frame rates would be perfectly fine with just busy spinning at that point" +in_reply_to: "" +parent_post_id: "2065840191340707905" +--- + +## Source + +- URL: https://x.com/rflaherty71/status/2065859701909459406 +- Author: Ryan Flaherty (@rflaherty71) +- Posted: 2026-06-13 18:11:49 + +## Branch + +**1/** + +@NOTimothyLottes Seems like people trying to push high frame rates would be perfectly fine with just busy spinning at that point + +**2/** + +@rflaherty71 Not exactly true, the larger problem is getting context switched at a bad time, so getting non-blocking bound comes with another set of dangers (higher bad preemption risk) + +**3/** + +@NOTimothyLottes @rflaherty71 All the more reason to go GPU-side where that can’t occur. + +**4/** + +@AgileJebrim @rflaherty71 Consumer GPU side is littered with junk these days, starting with multi display compositors. + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops]] diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while.md new file mode 100644 index 0000000..f9e679f --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while.md @@ -0,0 +1,64 @@ +--- +title: "Why not do a gradual sleeping? Start with" +type: archive +source: twitter +source_url: "https://x.com/winning_tactic/status/2065896862129733922" +author: "OZ" +handle: winning_tactic +post_id: "2065896862129733922" +date: 2026-06-13 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Why not do a gradual sleeping? Start with" +in_reply_to: "" +parent_post_id: "2065840191340707905" +--- + +## Source + +- URL: https://x.com/winning_tactic/status/2065896862129733922 +- Author: OZ (@winning_tactic) +- Posted: 2026-06-13 20:39:29 + +## Branch + +**1/** + +Why not do a gradual sleeping? Start with +while (spin--) { + asm volatile("pause" ::: "memory"); +} +then yield() +then yield 'til timer fire +gradually approaching longer spans? +You can have power modes that sets a lower threshhold to always yield and not spin e.g. or to have the particular levels based on eco/perf, and also it depends on the rest of the system to ensure spinning isn't a waste of cycles. + +But I've never considered a write to a dummy file as a legitimate yield/wait trigger. I wonder how that would fit in to my solution... + +**2/** + +@winning_tactic I don’t design around waiting for a specific point in time, I do other things, but talk about them when I can easily show the results + +**3/** + +Correct. But that's the point of gradually backoff, active spinlocking, then green thread yielding (cooperative other tasks, maybe even the one contesting) then kernel_poke (I guess that's what I would call that writing to file its a return from kernel-land immediately) then timer fired, the idea isn't to wait on a time, it's wait on an increasing value that changes tactics from the previous waits so that you don't really have to keep track of when what happens. +https://gitlab.com/qsrc.net/Lampyr/-/blob/dev/rt/time.c?ref_type=heads#L78 +But I've got to work on the power stuff and steal your idea of course. + +**4/** + +@winning_tactic Ahh the illusion of nonblocking execution on consumer devices. The moment the os decides to preempt your thread, there no longer exists a non blocking interface. A single thread never gets a guarantee of execution, so waiting for some exact point in time is failed design + +**5/** + +@NOTimothyLottes It's green threads multiplexed on pinned threads both cooperatively and preemptively. I beg your pardon!~ +https://gitlab.com/qsrc.net/Lampyr/-/blob/dev/rt/task.c?ref_type=heads +But, that particular version is a WIP, multiple impl and messy. + +## Related + +- Spine: [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops]] diff --git a/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/index.md b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/index.md new file mode 100644 index 0000000..e807834 --- /dev/null +++ b/archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/index.md @@ -0,0 +1,36 @@ +--- +title: "Interesting how on this Linux box, scheduling NOPs like nanosleep of 0 and futex waiting on an already set memory location … both take around 60 microseconds, cannot afford to do many of those per millisecond." +type: archive +source: twitter +source_url: "https://x.com/NOTimothyLottes/status/2065840191340707905" +author: "NOTimothyLottes" +handle: NOTimothyLottes +post_id: "2065840191340707905" +date: 2026-06-13 +archived: 2026-08-25 +draft: false +tags: + - archive + - twitter + - NOTimothyLottes +description: "Interesting how on this Linux box, scheduling NOPs like nanosleep of 0 and futex waiting on an already set memory location … both take around 60 microseconds, cannot afford to do many of those per millisecond." +in_reply_to: "" +--- + +## Source + +- URL: https://x.com/NOTimothyLottes/status/2065840191340707905 +- Author: NOTimothyLottes (@NOTimothyLottes) +- Posted: 2026-06-13 16:54:17 + +## Thread + +**1/** + +Interesting how on this Linux box, scheduling NOPs like nanosleep of 0 and futex waiting on an already set memory location … both take around 60 microseconds, cannot afford to do many of those per millisecond. Food for thought for high fps targets + +Branches: [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-rflaherty71-seems-like-people-trying-to-push-high-frame-rates]], [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-raggi-nanosleep-0-will-sleep-for-the-timer-slack-mm]], [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-winning_tactic-why-not-do-a-gradual-sleeping-start-with-while]], [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops/2026-06-13-BonbliStar-most-futex-impls-ive-seen-check-for-that-and]] + +**2/** + +A write of zero bytes is closer to say 6 microseconds in contrast, so just the user/kernel transition is expensive but 10x faster diff --git a/archive/threads/NOTimothyLottes/index.md b/archive/threads/NOTimothyLottes/index.md index cb709e3..58aff23 100644 --- a/archive/threads/NOTimothyLottes/index.md +++ b/archive/threads/NOTimothyLottes/index.md @@ -69,8 +69,8 @@ tags: - [[archive/threads/NOTimothyLottes/2026-06-03-back-running-640x480-on-my-vga-crts-to-prep-for]] - [[archive/threads/NOTimothyLottes/2026-06-10-so-im-on-linux-now-but-obviously-i-cheated]] - [[archive/threads/NOTimothyLottes/2026-06-13-cross-compilation-is-up]] +- [[archive/threads/NOTimothyLottes/2026-06-13-interesting-how-on-this-linux-box-scheduling-nops]] - [[archive/threads/NOTimothyLottes/2026-06-13-nanorc-done-and-back-to-actual-programming-with]] -- [[archive/threads/NOTimothyLottes/2026-06-13-the-glibc-implementation-would-do-that]] - [[archive/threads/NOTimothyLottes/2026-06-14-on-linux-i-do-speculative-pinning-of-cpu-memory]] - [[archive/threads/NOTimothyLottes/2026-06-26-quick-summary-of-why-not-pselect-ppoll-epoll]] - [[archive/threads/NOTimothyLottes/2026-06-27-deterrent-to-alsa-is-just-parsing-through-snd-pcm]]