Messages in this thread | | | From | Vincent Guittot <> | Date | Fri, 25 Jul 2014 19:57:47 +0200 | Subject | Re: [PATCH] sched: make update_sd_pick_busiest return true on a busier sd |
| |
On 25 July 2014 18:22, Rik van Riel <riel@redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/25/2014 12:05 PM, Peter Zijlstra wrote: >> On Fri, Jul 25, 2014 at 11:45:02AM -0400, Rik van Riel wrote: >>>> So for !ASYM the code is effectively: >>>> >>>> return sgs->avg_load > sds->busiest_stat.avg_load; >>>> >>>> I'd like to at least add a clause that makes overloaded groups >>>> prioritized over !overloaded groups. >>>> >>>> Also, like we found earlier, calculate_imbalance() relies on >>>> the sum_nr_running > group_capacity_factor thing, which you've >>>> just 'wrecked', so we'd need an update to that part too. >>> >>> I guess that would mean update_sd_pick_busiest would look like >>> this for the !ASYM case: >>> >>> 1) remembering whether busiest is overloaded >>> >>> 2) if (sgs->busiest_stat.overloaded && !sgs->overloaded) return >>> false; >>> >>> 3) if (sgs->avg_load > sds->busiest_stat.avg_load) return true; >> >> Right. So the situation I was worried about is where we have say 8 >> +nice tasks in one group and 2 -nice in another. So the group with >> 2 tasks can actually be 'heavier' but not fully utilized. In that >> case we want to pull tasks from the lighter but overloaded group. > > I can certainly create a new patch that makes update_sd_pick_busiest > do just that. > > Vincent, any objections to me fixing update_sd_pick_busiest now, or > will that conflict with your code cleanups?
It will probably conflict with my patchset which also modify update_sd_pick_busiest but we should be able to manage the conflict. So feel free to send a patch that fix the description above and we will see how to handle the conflict when it will occur
Vincent
> > - -- > All rights reversed > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJT0oRWAAoJEM553pKExN6DRdoH/2VsMEbeRdr9o99CYV3hK2bj > OT4O5xlz47aBq+/J3Sp35DZKtQ8PpYICNoNzddyF5Blr7ZcXB2OQj5Cv5Lj3Dtcs > q/AnJAN+6mDNq4B3aVfTb3BMDcrSz8LNdpNwVM80gfvbcZkcWIYWF2FigShIggMZ > bKz4cC5hVphtYR/WH6gnb5dXwgXBGYatwYsDXnVw6SLRbXcwYrB646SmZYXDVcER > bOj5IAjdfAlFkLbeow6OaX1arBrd6lyKfVI4Mzr848dqLBrJvmPvx/R4Z8EzPN2H > Gv4kqU7s9CAk1QOZLHWAOCDjG7PdMZfkS7WEZnQinMIutBK/jYJ4IXY8NNeS96I= > =OcR0 > -----END PGP SIGNATURE-----
| |