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.
[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