LWN: Comments on "ktask: optimizing CPU-intensive kernel work"

ktask: optimizing CPU-intensive kernel work

sroussey — Sat, 08 Dec 2018 16:48:02 +0000

There is an assumption here that memory bandwidth is tied per CPU, which is true now but not in EPIC2.

ktask: optimizing CPU-intensive kernel work

zlynx — Fri, 16 Nov 2018 00:39:19 +0000

With Optane and even faster Flash drives arriving on PCIe 4.0 soon, "I/O bound" needs to be removed from our vocabulary.

Don't expect things to be I/O bound. Networking and storage is poised to soon exceed the IO capability of a single CPU core.

ktask: optimizing CPU-intensive kernel work

dmjordan — Thu, 15 Nov 2018 13:48:59 +0000

There are other planned users in the cover letter too, like page freeing in the munmap/exit path.

ktask: optimizing CPU-intensive kernel work

darwish — Tue, 13 Nov 2018 23:13:39 +0000

>
> What uses beyond memory initialisation aka zero-filling pages is this supposed to have?
>

From the path series coverletter:

1) VFIO page pinning before kvm guest startup (others hitting slowness too[5])
2) deferred struct page initialization at boot time
3) clearing gigantic pages
4) fallocate for HugeTLB pages

[5] https://www.redhat.com/archives/vfio-users/2018-April/msg...

ktask: optimizing CPU-intensive kernel work

rweikusat2 — Mon, 12 Nov 2018 20:29:23 +0000

Shouldn't this be I/O bound?

ktask: optimizing CPU-intensive kernel work

hkario — Mon, 12 Nov 2018 18:12:24 +0000

resilvering btrfs theoretically could benefit from parallelism

ktask: optimizing CPU-intensive kernel work

rweikusat2 — Mon, 12 Nov 2018 16:35:51 +0000

What uses beyond memory initialisation aka zero-filling pages is this supposed to have?