The Linux Scheduler: A Decade of Wasted Cores (2016) • Hacker News Board

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#11

Post by Filligree » Mon, Oct 23, 2017, 4:34 PM UTC

Somewhat relevant: Threadripper CPUs, which are aimed at the high-end consumer market, are NUMA with two memory domains.

This makes the overall scheduling problem much harder, to the point that they were built with a special "Disable half the cores" mode and supporting hardware to give both memory banks same-speed access to the remaining ones.

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#12

Post by dragontamer » Mon, Oct 23, 2017, 4:38 PM UTC

pdw wrote: post #6

tkyjonathan wrote: post #5

DBAs knew about this for many years now. We would simply change the schedular on the DB servers.

I think you might be confusing CPU schedulers and IO schedulers. Linux never had switchable CPU schedulers.

Alternatively, it might be a confusion between Linux and Windows.

https://technet.microsoft.com/en-us/library/aa175393(v=sql.8...

The Windows Database team has been using the "User Mode Scheduling" feature of Windows to implement custom scheduling for databases for some time.

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#13

Post by amyjess » Mon, Oct 23, 2017, 5:07 PM UTC

pdw wrote: post #6

tkyjonathan wrote: post #5

DBAs knew about this for many years now. We would simply change the schedular on the DB servers.

I think you might be confusing CPU schedulers and IO schedulers. Linux never had switchable CPU schedulers.

Mainline, sure, but there are other kernel forks that do, such as the ck kernel.

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#14

Post by hesdeadjim » Mon, Oct 23, 2017, 5:31 PM UTC

Filligree wrote: post #11

Somewhat relevant: Threadripper CPUs, which are aimed at the high-end consumer market, are NUMA with two memory domains. This makes the overall scheduling problem much harder, to the point that they were built with a special "Disable half the cores" mode and supporting hardware to give both memory banks same-speed access to the remaining ones.

Honestly, I believe the only reason they did this is so that when review sites run benchmarks the Threadripper won't look abnormally slow compared to the other chips out there.

I own one and in both work and play I have had zero issues. If I drop a frame here and there in a game due to some memory latency? Eh, could care less. If you can afford a Threadripper you can afford a 1080 Ti and a Gsync monitor to smooth out any issues you might run into.

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#15

Post by brendangregg » Mon, Oct 23, 2017, 5:37 PM UTC

Still 0% performance wins for Netflix. Not a "decade of wasted cores" for us.

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#16

Post by diptanu » Mon, Oct 23, 2017, 5:44 PM UTC

brendangregg wrote: post #15

Still 0% performance wins for Netflix. Not a "decade of wasted cores" for us.

Can you please explain that more?

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#17

Post by cat199 » Mon, Oct 23, 2017, 5:45 PM UTC

pdw wrote: post #6

tkyjonathan wrote: post #5

DBAs knew about this for many years now. We would simply change the schedular on the DB servers.

I think you might be confusing CPU schedulers and IO schedulers. Linux never had switchable CPU schedulers.

not to mention the fact that kernel devs knew about it as well, so the whole title of the article is a bit bunk

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#18

Post by dullgiulio » Mon, Oct 23, 2017, 5:54 PM UTC

ksk wrote: post #10

CalChris wrote: post #7

> The evolution of scheduling in Linux By and large, by the year 2000, operating systems designers considered scheduling to be a solved problem… If I recall correctly, 2000 is 2.3.x which had a braindead trivial scheduler. Basically it just looped through the process list and executed goodness() and found the 'best'. This was obscenely slow when there were a lot of dormant processes. The process table links all mappe…

From my experience, Linux CPU and I/O scheduling got good from 2.6.x (also around 2007) around when AIO became robust.

Isn't AIO still implemented with threads in libc? In that case, it's just the CPU scheduler that counts...

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#19

Post by the_why_of_y » Mon, Oct 23, 2017, 6:04 PM UTC

diptanu wrote: post #16

brendangregg wrote: post #15

Still 0% performance wins for Netflix. Not a "decade of wasted cores" for us.

Can you please explain that more?

The paper has a clickbaity title, but the actual performance impact of the scheduler behaviors discussed therein is negligible on many workloads. YMMV.

Re: The Linux Scheduler: A Decade of Wasted Cores (2016)

#20

Post by noughth » Mon, Oct 23, 2017, 6:42 PM UTC

ksk wrote: post #9

noughth wrote: post #8

Earlier quoted context omitted.

Sure it does: http://man7.org/linux/man-pages/man2/sched_setscheduler.2.ht...

If you read the page, it simply states that you can tweak the parameters of the existing scheduler, not replace it entirely.

The scheduling policies listed on the man page I linked share some generic kernel code, but I wouldn't classify them as the same scheduler. If you look inside the kernel/sched/ directory in the source, you'll find that an instance of `struct sched_class` is defined for each scheduler class. There are dl_sched_class, rt_sched_class, fair_sched_class, and idle_sched_class. You can see in `pick_next_task` in core.c that these class structs are iterated over, calling into each scheduler's own `pick_next_task`: http://elixir.free-electrons.com/linux/v4.13.9/source/kernel...