My problem is probably the same that Doug Smythies described in bug 1626564 . I used the "echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event" method and had about 1000 work items enqueued by "memcg_kmem_cache_create_func" all at pretty much the same time, which correlates nicely with the 1000 kworker processes I see after boot.
If Martin has the same issue with lots of kworkers (I'm still not quite sure?), this might be the same issue.
So I suspect the bad commit might be:
81ae6d03952c1bfb96e1a716809bd65e7cd14360
"mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink()"
according to https://bugzilla.kernel.org/show_bug.cgi?id=172991
My problem is probably the same that Doug Smythies described in bug 1626564 . I used the "echo workqueue: workqueue_ queue_work > /sys/kernel/ debug/tracing/ set_event" method and had about 1000 work items enqueued by "memcg_ kmem_cache_ create_ func" all at pretty much the same time, which correlates nicely with the 1000 kworker processes I see after boot.
If Martin has the same issue with lots of kworkers (I'm still not quite sure?), this might be the same issue.
So I suspect the bad commit might be: b96e1a716809bd6 5e7cd14360 cpus_sync( ) with synchronize_sched() in kmem_cache_ shrink( )" /bugzilla. kernel. org/show_ bug.cgi? id=172991
81ae6d03952c1bf
"mm/slub.c: replace kick_all_
according to https:/
This commit was released in Linux 4.7.
This patch might fix the issue, but I haven't tested it: /patchwork. kernel. org/patch/ 9359271/
https:/