Low Latency Optimization: Understanding Pages (Part 1)
hudsonrivertrading.com
Low Latency Optimization: Understanding Pages (Part 1)
1–10 of 59 posts
Re: Low Latency Optimization: Understanding Pages (Part 1)
#2Feels a bit blogspammy. Drepper's article is linked to for good reason
Re: Low Latency Optimization: Understanding Pages (Part 1)
#3Feels a bit blogspammy. Drepper's article is linked to for good reason
They don’t want to release actually interesting optimization content but need something to fill the tech blob maybe?
Although huge pages are pretty basic table stakes for hft software nowadays, not much alpha left to high by really going into detail on them?
Re: Low Latency Optimization: Understanding Pages (Part 1)
#4Low latency trading (sometimes referred as HFT as well) focuses a lot in data locality. That is to make sure the critical path, that is from market data coming in to new order or cancel order sending out (tick-to-trade), operates in cache as much as possible and avoid memory access as much as possible. Put all those needed data together within few cachelines as possible. To make sure those data are in the cache so the tick-to-trade operates on cache, sometimes warmup of caches between orders are employed too. This is to prevent those caches swapped out, and involves sending fake orders that won't actually go out, but swapped in the needed cachelines before the real orders, so that caches are hot when they are needed.
Re: Low Latency Optimization: Understanding Pages (Part 1)
#5An OS page size is such a prevalent notion in software it's shocking
I was oblivious to this a year ago before I got interested in database internals
Something that I found interesting, there's a recent presentation by Neumann about the Umbra DBMS where he fields a question about hugepages at the end. I recall him saying they don't use it, which I found interesting.
I know Oracle and MySQL recommended Transparent Hugepages IIRC
Re: Low Latency Optimization: Understanding Pages (Part 1)
#6So useless.
Re: Low Latency Optimization: Understanding Pages (Part 1)
#7If you're doing truly low latency stuff you shouldn't be swapping at all, everything should be 100% resident in memory at all times. So "pages" are totally irrelevant to you. (You should also probably be using something like the PREEMPT_RT patchset, adjust scheduling priorities and try your best to ensure that the CPU core(s) your app is running on aren't burdened by serving interrupts. Plus likely a lot of other stuff that I haven't touched on in this brief comment.)
Re: Low Latency Optimization: Understanding Pages (Part 1)
#8If you're doing truly low latency stuff you shouldn't be swapping at all, everything should be 100% resident in memory at all times. So "pages" are totally irrelevant to you. (You should also probably be using something like the PREEMPT_RT patchset, adjust scheduling priorities and try your best to ensure that the CPU core(s) your app is running on aren't burdened by serving interrupts. Plus likely a lot of other stu…
Pages still exist even if you disable swap. Maybe you could benefit from reading TFA?
Re: Low Latency Optimization: Understanding Pages (Part 1)
#9If you're doing truly low latency stuff you shouldn't be swapping at all, everything should be 100% resident in memory at all times. So "pages" are totally irrelevant to you. (You should also probably be using something like the PREEMPT_RT patchset, adjust scheduling priorities and try your best to ensure that the CPU core(s) your app is running on aren't burdened by serving interrupts. Plus likely a lot of other stu…
Stock / near stock Linux is pretty close to fine for HFT.
You basically only interact with the kernel on init/shutdown or outside of the fast path, and do something like isolcpus to delegate the kernel and interrupt handling to some garbage cores and give you the rest to do what you want with.
Re: Low Latency Optimization: Understanding Pages (Part 1)
#10If you're doing truly low latency stuff you shouldn't be swapping at all, everything should be 100% resident in memory at all times. So "pages" are totally irrelevant to you. (You should also probably be using something like the PREEMPT_RT patchset, adjust scheduling priorities and try your best to ensure that the CPU core(s) your app is running on aren't burdened by serving interrupts. Plus likely a lot of other stu…
Stock / near stock Linux is pretty close to fine for HFT. You basically only interact with the kernel on init/shutdown or outside of the fast path, and do something like isolcpus to delegate the kernel and interrupt handling to some garbage cores and give you the rest to do what you want with.
Your comment is correct but might cause readers to underestimate how annoying this tuning work is and how difficult it is to get everything into hugepages (executable memory and stack memory and shared libraries if applicable, not just specific heap allocations). We are trading a joke asset class on joke venues that have millisecond-scale jitter, so we can get away with using io_uring instead of kernel bypass networking.