# Pathological scheduler behavior on specific AWS instance types

**URL:** <https://erlangforums.com/t/pathological-scheduler-behavior-on-specific-aws-instance-types/4835>\
**Category:** Questions / Help\
**Tags:** performance, schedulers, aws, message-pass\
**Created:** [June 16, 2025, 1:36pm UTC](https://erlangforums.com/t/pathological-scheduler-behavior-on-specific-aws-instance-types/4835 "2025-06-16T13:36:51Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![dch](https://erlangforums.com/user_avatar/erlangforums.com/dch/32/962_2.png) [@dch](https://erlangforums.com/u/dch)\
**Post date:** [June 18, 2025, 8:07pm UTC](https://erlangforums.com/t/pathological-scheduler-behavior-on-specific-aws-instance-types/4835/5 "2025-06-18T20:07:56Z")

</div>

Do you understand the physical layout of CPU cores in these systems?

> **[4th Gen Intel Xeon Processor Scalable Family, sapphire rapids](https://www.intel.com/content/www/us/en/developer/articles/technical/fourth-generation-xeon-scalable-family-overview.html)**
>
> A technical overview of the 4th Gen Intel® Xeon® Processor Scalable Family based on the formerly codenamed Sapphire Rapids architecture.

There are groups of efficient high bandwidth cores, called chiplets or tiles. These groups connect via comparatively slow interconnects.

If a thread migrates between cores within a chiplet the on-cpu cache is lost and must be refeched from the next level.

If the thread migrates between chiplets the same thing happens but the performance hit is much much worse and more cache is lost.

We want the BEAM to not migrate cpu core because of this.

Generally on these types of systems you pin processes (incl network cards, OS processes, BEAM processes) to specific cores to avoid this massive penalty.

you trade off a lot of flexibility though.

You may well get better performance by pinning BEAM schedulers _and_ running multiple BEAMs too, isolating each one within a chiplet, and thus avoiding crossing.

The design of these systems is usually targeted to hyperscaler cloud vendors, and who use VMs to subdivide onto tiles.

Consider trying the larger arm64 CPUs for comparison, their internal architecture is less susceptible to this.

But mostly try pinning all BEAM and OS processes to specific cores to avoid crossing the chiplet chasm.

Also retry specifically with hyperthreading disabled and see if that helps.

There are some serious tools on intel platforms to examine this and see what CPUs are doing but it’s not lightweight, look for talks books and content by Brendan Gregg he’s the legend in this space.

> **[Brendan Gregg's Homepage](https://www.brendangregg.com/)**
>
> Brendan Gregg's homepage: I use this site to share various things, mostly my work with computers, specifically, computer performance analysis and methodology.

[https://erlangforums.com/t/beam-on-128-core-linux-box-seeming-not-to-use-many-of-available-cores/](https://erlangforums.com/t/beam-on-128-core-linux-box-seeming-not-to-use-many-of-available-cores/) this thread has a lot of relevant info too

And it might also be that the cpu just sucks [Bug Forces Intel to Halt Some Xeon Sapphire Rapids Shipments | Tom's Hardware](https://www.tomshardware.com/news/bug-forces-intel-to-halt-sapphire-rapids-shipments)

---

_[View the full topic](https://erlangforums.com/t/pathological-scheduler-behavior-on-specific-aws-instance-types/4835)._