From: Peter Zijlstra <firstname.lastname@example.org> To: Phil Auld <email@example.com> Cc: Dave Chinner <firstname.lastname@example.org>, Ming Lei <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Jeff Moyer <firstname.lastname@example.org>, Dave Chinner <email@example.com>, Eric Sandeen <firstname.lastname@example.org>, Christoph Hellwig <email@example.com>, Jens Axboe <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Tejun Heo <firstname.lastname@example.org>, Vincent Guittot <email@example.com> Subject: Re: single aio thread is migrated crazily by scheduler Date: Thu, 21 Nov 2019 14:29:37 +0100 Message-ID: <20191121132937.GW4114@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <20191120220313.GC18056@pauld.bos.csb> On Wed, Nov 20, 2019 at 05:03:13PM -0500, Phil Auld wrote: > On Wed, Nov 20, 2019 at 08:16:36PM +0100 Peter Zijlstra wrote: > > On Tue, Nov 19, 2019 at 07:40:54AM +1100, Dave Chinner wrote: > > > Yes, that's precisely the problem - work is queued, by default, on a > > > specific CPU and it will wait for a kworker that is pinned to that > > > > I'm thinking the problem is that it doesn't wait. If it went and waited > > for it, active balance wouldn't be needed, that only works on active > > tasks. > > Since this is AIO I wonder if it should queue_work on a nearby cpu by > default instead of unbound. The thing seems to be that 'unbound' is in fact 'bound'. Maybe we should fix that. If the load-balancer were allowed to move the kworker around when it didn't get time to run, that would probably be a better solution. Picking another 'bound' cpu by random might create the same sort of problems in more complicated scenarios. TJ, ISTR there used to be actually unbound kworkers, what happened to those? or am I misremembering things. > > Lastly, > > one other thing to try is -next. Vincent reworked the load-balancer > > quite a bit. > > > > I've tried it with the lb patch series. I get basically the same results. > With the high granularity settings I get 3700 migrations for the 30 > second run at 4k. Of those about 3200 are active balance on stock 5.4-rc7. > With the lb patches it's 3500 and 3000, a slight drop. Thanks for testing that. I didn't expect miracles, but it is good to verify. > Using the default granularity settings 50 and 22 for stock and 250 and 25. > So a few more total migrations with the lb patches but about the same active. Right, so the granularity thing interacts with the load-balance period. By pushing it up, as some people appear to do, makes it so that what might be a temporal imablance is perceived as a persitent imbalance. Tying the load-balance period to the gramularity is something we could consider, but then I'm sure, we'll get other people complaining the doesn't balance quick enough anymore.
next prev parent reply index Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-14 11:31 Ming Lei 2019-11-14 13:14 ` Peter Zijlstra 2019-11-15 0:09 ` Ming Lei 2019-11-15 14:16 ` Ming Lei 2019-11-14 23:54 ` Dave Chinner 2019-11-15 1:08 ` Ming Lei 2019-11-15 4:56 ` Dave Chinner 2019-11-15 7:08 ` Ming Lei 2019-11-15 23:40 ` Dave Chinner 2019-11-16 6:31 ` Ming Lei 2019-11-18 9:21 ` Peter Zijlstra 2019-11-18 14:54 ` Vincent Guittot 2019-11-18 20:40 ` Dave Chinner 2019-11-20 19:16 ` Peter Zijlstra 2019-11-20 22:03 ` Phil Auld 2019-11-21 4:12 ` Ming Lei 2019-11-21 14:12 ` Phil Auld 2019-11-21 15:02 ` Boaz Harrosh 2019-11-21 16:19 ` Jens Axboe 2019-12-09 16:58 ` Srikar Dronamraju 2019-11-21 22:10 ` Dave Chinner 2019-11-21 13:29 ` Peter Zijlstra [this message] 2019-11-21 14:21 ` Phil Auld 2019-12-09 16:51 ` Srikar Dronamraju 2019-12-09 23:17 ` Dave Chinner 2019-12-10 3:27 ` Srikar Dronamraju 2019-12-10 5:43 ` [PATCH v2] sched/core: Preempt current task in favour of bound kthread Srikar Dronamraju 2019-12-10 9:26 ` Peter Zijlstra 2019-12-10 9:33 ` Peter Zijlstra 2019-12-10 10:18 ` Srikar Dronamraju 2019-12-10 10:16 ` Srikar Dronamraju 2019-12-10 9:43 ` Vincent Guittot 2019-12-10 10:11 ` Srikar Dronamraju 2019-12-10 11:02 ` Vincent Guittot 2019-12-10 17:23 ` [PATCH v3] " Srikar Dronamraju 2019-12-11 17:38 ` [PATCH v4] " Srikar Dronamraju 2019-12-11 22:46 ` Dave Chinner 2019-12-12 10:10 ` Peter Zijlstra 2019-12-12 10:14 ` Peter Zijlstra 2019-12-12 10:23 ` Peter Zijlstra 2019-12-12 11:20 ` Vincent Guittot 2019-12-12 13:12 ` Peter Zijlstra 2019-12-12 15:07 ` Srikar Dronamraju 2019-12-12 15:15 ` Peter Zijlstra 2019-12-13 5:32 ` Srikar Dronamraju 2019-11-18 16:26 ` single aio thread is migrated crazily by scheduler Srikar Dronamraju 2019-11-18 21:18 ` Dave Chinner 2019-11-19 8:54 ` Ming Lei [not found] ` <firstname.lastname@example.org> 2019-11-28 9:53 ` Vincent Guittot 2019-12-02 2:46 ` Ming Lei 2019-12-02 4:02 ` Dave Chinner 2019-12-02 4:22 ` Ming Lei 2019-12-02 13:45 ` Vincent Guittot 2019-12-02 21:22 ` Phil Auld 2019-12-03 9:45 ` Vincent Guittot 2019-12-04 13:50 ` Ming Lei 2019-12-02 23:53 ` Dave Chinner 2019-12-03 0:18 ` Ming Lei 2019-12-03 13:34 ` Vincent Guittot 2019-12-02 7:39 ` Juri Lelli 2019-12-02 3:08 ` Dave Chinner [not found] ` <email@example.com> 2019-12-02 23:06 ` Dave Chinner [not found] ` <firstname.lastname@example.org> 2019-12-03 22:29 ` Dave Chinner [not found] ` <email@example.com> 2019-12-04 22:59 ` Dave Chinner
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191121132937.GW4114@hirez.programming.kicks-ass.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-XFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-xfs/0 linux-xfs/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-xfs linux-xfs/ https://lore.kernel.org/linux-xfs \ firstname.lastname@example.org public-inbox-index linux-xfs Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-xfs AGPL code for this site: git clone https://public-inbox.org/public-inbox.git