Basically, I want to have an embedded-linux to run a single application, but with minimum kernel process and minimum userland process:

  • I don't really care the size of kernel or root file system. (surely a thin one is still preferred.)
  • so extra built-in modules in kernel are fine, so long as they don't run when unnecessary. Maybe I can use/activate them later
  • And I still need some kernel process for monitoring purpose, so that I can run commands "ps", "top", etc.
  • I know I can enable/disable userland process by changing "Init" program, right?
  • But how do I enable/disable kernel process?
  • ---- how do I know what kernel process are needed for my application?


  • Hi @Jerry, welcome to Unix & Linux at StackExchange! You might want to make your question more specific, as it stands it's too broad... I guess you're referring to the kernel threads such as [kworker/*], [ksoftirqd/N], [kswapdN], [kblockd] and many others, is that the case? While in some cases you might be able to disable kernel behavior that spawns these threads, in some cases it is not possible. Do you have any evidence that these are really causing undue overhead for your system? In a way, kernel devs decided using those was the most efficient implementation, they're actually normal
    – filbranden
    Commented Jan 10, 2019 at 20:30
  • It sounds like you want to compile a minimal kernel from scratch and use a minimal init with maybe busybox instead of the GNU ecosystem to provide the user level tools. However, it's not clear whether I should turn this into an answer since you're really asking multiple questions each broad enough to have multiple alternative answers.
    – cryptarch
    Commented Jan 10, 2019 at 20:37
  • "how do I know what kernel process are needed for my application?" -- How do we know what your application is? Best recommendation; read, read, get some good kernel books, and keep reading. If you have a question about a specific kernel process, feel free to update your post!
    – bgregs
    Commented Jan 10, 2019 at 20:37
  • You might want to check out the concept of "unikernel" e.g. next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-linux Commented Jan 10, 2019 at 20:39
  • @filbranden understands what I want to ask! I am indeed asking a general question. and I don't have any poof about latency due to those kernel processes. Just by intuition: the more unnecessary processes being removed, the best!
    – Jerry
    Commented Jan 10, 2019 at 21:02

1 Answer 1


There is no general way to disable kernel threads individually, since they exist to support specific kernel APIs (such as [kworker/*] threads for workqueues) or subsystems (such as the threads involved in flushing and other background tasks on the block subsystem) or modules (such as threads used to manage filesystems, the device mapper, etc.)

In some cases, you can't really disable them, since the kernel API using them is not really optional and doesn't provide an alternative way to provide the same feature without using a kernel thread, as it's the case with workqueues. (The kernel developers have worked to reduce the total number of threads used by that API, though.)

In some cases, you can disable some threads, but usually only by disabling the whole kernel subsystem or module with them. For instance, you won't have the ext4 kernel threads around if you're not using ext4 anymore...

I think you're asking the wrong question here... The kernel threads are not the cause of overhead. Usually, it's the other way around. Certain procedures and callbacks have been moved into kernel threads so they could be run more efficiently, reusing the kernel scheduler to get them to run periodically in background, rather than coming up with seaparate mechanisms to do the same...

Kernel threads don't really take up extra memory, they just share the kernel address space. (Ok, technically you'll need an extra task_struct for each thread, but that's mostly irrelevant, even on an embedded system.)

Disabling kernel features for an embedded system does make sense, but you should focus on specific kernel configs you don't need or configs you can tweak, rather than at the kernel threads that are running. Those may be very visible (when you run ps, etc.) but as explained above, that doesn't mean they're really using resources of your system. So if you're looking for gains in efficiency, you're more likely to find useful ones elsewhere, rather than focusing on the kernel threads.

  • Let me summarize with my own words, and see if I fully understand what you mean. (By the way: I am actually focusing on "real-time" performance of an embedded system!). Even though kernel threads don't use much extra memory, kernel threads do consume time slices, right? As I am focusing on "real-time" performance, so some extra memory is not an issue for me. But can you clarify how much the time-slice overheads of kernel threads might affect the "real-time" performance?
    – Jerry
    Commented Jan 11, 2019 at 15:36
  • Also, kernel threads might be removed/disappeared by tweaking kernel configs before building the kernel. And this method is the most appropriate/recommended solution for reducing kernel threads, right?
    – Jerry
    Commented Jan 11, 2019 at 15:36
  • ( weird, I can't edit my previous comments? )
    – Jerry
    Commented Jan 11, 2019 at 18:14
  • @Jerry If your interest is in real time, you might want to look into the -rt patchset for the Linux kernel. See the Linux-RT Wiki for details, the Arch Linux documentation for it is a great starting point too (even if you're not using Arch Linux.) Note that the -rt patchset in fact increases the number of kernel threads, since managing scheduling deadline is easier on the scheduler!
    – filbranden
    Commented Jan 12, 2019 at 6:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .