ktask: multithread cpu-intensive kernel work

Session information has not yet been published for this event.

*
Unconference I
Microconference Session

One Line Summary

As memory size and CPU counts increase on the largest systems, certain paths in the kernel that are single-threaded today are not scaling well and will become even bigger bottlenecks in the future. Examples include zeroing the biggest huge pages (e.g. 1G on x86), walking a process’s entire page table, and freeing large ranges of pages.

These paths have been well optimized in one thread, so now it's a matter of scaling up the CPUs to match the amount of work to be done.

One solution to this problem is ktask, a generic framework built on top of workqueues that takes care of splitting up a large task, starting a number of threads appropriate for the size of the task and the system, and load balancing the work between these threads. ktask uses internal limits to maintain an appropriate level of concurrency across the system.

I want to get feedback on the overall approach and discuss similar scalability issues others are having in the kernel.

Abstract

As memory size and CPU counts increase on the largest systems, certain paths in the kernel that are single-threaded today are not scaling well and will become even bigger bottlenecks in the future. Examples include zeroing the biggest huge pages (e.g. 1G on x86), walking a process’s entire page table, and freeing large ranges of pages.

These paths have been well optimized in one thread, so now it’s a matter of scaling up the CPUs to match the amount of work to be done.

One solution to this problem is ktask, a generic framework built on top of workqueues that takes care of splitting up a large task, starting a number of threads appropriate for the size of the task and the system, and load balancing the work between these threads. ktask uses internal limits to maintain an appropriate level of concurrency across the system.

I want to get feedback on the overall approach and discuss similar scalability issues others are having in the kernel.

Back to list of proposals

Speaker

  • Photo_james_w800

    James E.J. Bottomley

    IBM Research

    Biography

    James Bottomley is a Distinguished Engineer at IBM Research where he
    works on Cloud and Container technology. He is also Linux Kernel
    maintainer of the SCSI subsystem. He has been a Director on the Board
    of the Linux Foundation and Chair of its Technical Advisory Board. He
    went to university at Cambridge for both his undergraduate and
    doctoral degrees after which he joined AT&T Bell labs to work on
    Distributed Lock Manager technology for clustering. In 2000 he helped
    found SteelEye Technology, a High availability company for Linux and
    Windows, becoming Vice President and CTO. He joined Novell in 2008 as
    a Distinguished Engineer at Novell’s SUSE Labs, Parallels (later Odin)
    in 2011 as CTO of Server Virtualization and IBM Research in 2016.