Messages in this thread | | | Date | Mon, 18 Dec 2017 11:25:15 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH 4/4] sched: Allow tasks to stack with a workqueue on the same CPU |
| |
On Mon, Dec 18, 2017 at 11:44:30AM +0100, Mike Galbraith wrote: > On Mon, 2017-12-18 at 09:43 +0000, Mel Gorman wrote: > > If tasks wake a kworker to do some work and is woken on completion and it > > was a per-cpu kworker that was used then a situation can arise where the > > current CPU is always active when the kworker is waking and select_idle_sibling > > moves the task. This leads to a situation where a task moves around the socket > > each time a kworker is used even through the relationship is effectively sync. > > This patch special cases a kworker running on the same CPU. It has a noticable > > impact on migrations and performance of dbench running with the XFS filesystem > > but has no impact on ext4 as ext4 interacts with a kthread, not a kworker. > > I think intentional stacking is a very bad idea unless you know with > absolute certainty that waker/wakee are in fact 100% synchronous. This > is IMO the wrong way to go about combating the excessive bouncing, that > can be achieved by simple ratelimiting. >
Grand, I thought the patch was a bit optimistic but was surprised at the level of impact for a workload that really did have a synchronous relationship between waker and wakee. Might be worth revisiting it in the future, be it rate-limiting or some other mechanism.
Thanks.
-- Mel Gorman SUSE Labs
| |