from Hacker News

Core scheduling lands in Linux 5.14

by phab on 11/2/21, 12:45 AM with 72 comments

  • by earthscienceman on 11/2/21, 4:11 AM

    This is such a great post, I'm surprised it doesn't have more traction but maybe people aren't into reading longform plain text.

    "spamming Internet users at scale requires a lot of parallel activity, after all. If those processes can be segregated so that all siblings of any given core run processes from the same customer, we can be spared the gruesome prospect of one spammer stealing another's target list — or somebody else's private keys."

  • by ww520 on 11/2/21, 7:16 AM

    That's very fast in adding the feature to kernel to address the loss of performance due to Sprectre.

    Assigning OS threads of the same process to the hyperthreads in the same core is a good thing anyway. The threads probably share many data in the process and can benefit from the shared cache in the core.

  • by po1nt on 11/2/21, 8:54 AM

    Everything is cool, except for the naming. At first I thought this was about implementation of Intel's new architecture.

  • by tpxl on 11/2/21, 7:34 AM

    Is there not a way to pin processes to cores in linux already, and/or why it cannot be used to achieve a similar thing (pin user1 to cores 0,1 and user2 to cores 2,3)?

  • by OldHand2018 on 11/2/21, 3:36 PM

    The first link in the linked article mentions Linus saying (in 2019) that performance needs to be better than simply running with SMT disabled.

    There is no mention of performance though. How is it? Presumably it is better!! And if so, this sounds like a concept that the OpenBSD community would be interested in since they prefer SMT disabled for security reasons.

  • by kevin_thibedeau on 11/2/21, 4:43 AM

          int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5);
    Is there a reason why a more idiomatic void * to struct wasn't used for the args?

  • by jimmyed on 11/2/21, 11:11 AM

    > When one sibling is executing, the other must wait. SMT is useful because CPUs often go idle while waiting for events — usually the arrival of data from memory. While one CPU waits, the other can be executing

    Is this accurate? I was under the impression SMT gains are not from running other threads when one is blocked (preemption is a old feature) but the processor having a multi stage pipeline so that the net number of instructions that are executed per cycle is more than 1 (closer to 2 in the above example)

  • by jeff_vader on 11/2/21, 6:59 PM

    Random question: does anyone use recent mainline kernels with Ubuntu 20.04? How? How's the experience?

    I'm currently on Ubuntu HWE line, but that only goes to 5.11.0. Ubuntu kernel devs have debs for [mainline][1], but I'm not finding any good feedback/experience stories about these.

    [1]: https://kernel.ubuntu.com/~kernel-ppa/mainline/

  • by exabrial on 11/2/21, 12:02 PM

    > While one might argue that cloud-computing providers are usually grumpy anyway, there is still value in anything that might improve their mood.

    I'm dead haha. This is great.

  • by 656565656565 on 11/3/21, 7:59 AM

    I’m surprised this has made into the mainline kernel, it feels like it is a niche use case. Perhaps cloud provider pressure?