LaurieWired/tailslayer

would be nice if you could mention this issue somehow that we get a ping if this could get into production or something like that :)
also i dont understand what you mean with saving power? becaus as far as i understand, the idea is to save the data on 2 different ram (channels), so it literally takes 2 times the power for sending and recieving it and also for throwing it away if the other request was faster. Yes the program who requests the data is than faster in being finished and does not need to wait "so long", but could you explain to me where you think it could safe power? I'm serious about this—I'm not joking—and I'd really like to understand.

Good catches, all three. Fixed:
prefetch_race now reads both channels and takes the min. The p50 win is mostly NTA prefetch warming the fill buffer, not true channel racing (second read is serialized after the first). Updated the comment to say that
Combined danger path, same fix.
Lockless pairing switched to timestamp-window matching (500 cycle max delta) to match the methodology in benchmark.cpp.
The numbers in the issue are from the pre-fix version. Will re-run and update the tables and code soon.

- prefetch_race claims “read whichever prefetch won”, but it always loads addr_ch0. See ablation.cpp:254 to ablation.cpp:257
- combined does the same in its danger path.
- lockless_hedged switched from timestamp-window pairing in benchmark.cpp:211 to plain index pairing in ablation.cpp:342 ... ablation.cpp:355 That is faster and simpler, but it is also less rigorous.

The solution to most things is not to introduce more complexity.

The way its done is ALREADY the most optimal way of solving the problem of avoiding tail latency. The fact that tail latency is already only present in such a vanishingly small percentile, makes it irrelevant to 99% of applications. Could the video have done a better job of explaining how well the problem has been engineered around already? Sure.

But you are tackling a different problem here, and at the completely wrong scale. And even the first sentence is patently false: you can't control the placement, it's done by circuits etched in memory controllers. You can only check what they're doing, and avoid them getting in your way.

The engineering has been solved: [RLDRAM](https://en.wikipedia.org/wiki/RLDRAM)

This solution is specifically to use general purpose computers to do things normally done with specialized hardware. Being able to work around it with software is delightful to say the least.

I'm sure there a...

Kind of a funny (AI?) post I've read... Even IF it were a problem, I believe I have an idea how hardware designers could easily patch it off quite trivially without too much of a performance penalty.

Assuming it was so much of a problem that even hardware designers themselves have to step in, 1 idea is they could for instance be having a random rotating seed that's initialized on startup and then each time the cpu has to assign a virtual address or piece of memory some physical block of memory, instead of making it based on some kind of offsets, make the decision which channel data goes to based on the seed.
The cpu would internally have a timer to rotate the seed (nextRotation for example could also introduce variable random dynamic jitter and overall be anything between 40 ms and 80 ms into the future), and all this could also be based on how fast the actual processor is so attackers can't easily figure out what the seed is within the window where rotation hasn't occurred yet).

The...

This AI doesn't know what it's talking about. It wouldn't make any sense to make the channel choice random, especially because there are only two channels in most systems. Maybe it's thinking that this project is the actual algorithm the memory controllers use? But regardless, this issue is complete nonsense.

Nice to see some good patches! You can make some tests, and if you don't spot any regressions or breakages, try pushing it in the mainline Linux git repo through the LKML

[ablation.cpp.txt](https://github.com/user-attachments/files/26570018/ablation.cpp.txt)

Good thing I checked this repo's issues (and went deeper than the schizo active ones...).
I was just about to attempt a similar implementation. 😆

so what have I done wrong ? also I think I have 16x channels





@dagelf using your fork

> Don't worry, your OS can handle it. But if you can't: [#5](https://github.com/LaurieWired/tailslayer/pull/5) 😄

It sure can, just need to increase huge table max size (2M currently).

Don't worry, your OS can handle it. But if you can't: https://github.com/LaurieWired/tailslayer/pull/5 😄

I was thinking it would save power, and smooth out RT kernels response time

Pretty cool. Do you have a particular use-case for this? I wonder where this sort of nano second scale latency / jitter could cause real problems that are not outweighed by OS latency.

No worries, it is still very much experimental code :)