Messages in this thread | | | From | Paul Turner <> | Date | Thu, 11 Nov 2010 03:13:00 -0800 | Subject | Re: [tg_shares_up rewrite v2 10/11] sched: allow update_cfs_load to update global load |
| |
Ah, I should have checked that, sorry.
I've fixed these errors for a v3. But in fixing them I've realized I think we have a race in sched_destroy_group() (in patch 2/11).
While it's true that we are safe for a subsequent enqueue in the same group, we're not protected against a list element being removed due to decay in the update shares path. Or from a another group being enqueued (via wake-up).
Might as well fix this at the same time so I'll fix it and send out in the morning.
Thanks!
On Wed, Nov 10, 2010 at 8:50 PM, David Miller <davem@davemloft.net> wrote: > From: David Miller <davem@davemloft.net> > Date: Wed, 10 Nov 2010 20:47:04 -0800 (PST) > >> From: Paul Turner <pjt@google.com> >> Date: Wed, 10 Nov 2010 19:50:15 -0800 >> >>> Refactor the global load updates from update_shares_cpu() so that >>> update_cfs_load() can update global load when it is more than ~10% out of sync. >>> >>> The new global_load parameter allows us to force an update, regardless of >>> the error factor so that we can synchronize w/ update_shares(). >>> >>> Signed-off-by: Paul Turner <pjt@google.com> >> >> This patch breaks the build, you didn't update the arguments of >> update_cfs_load() in the !CONFIG_FAIR_GROUP_SCHED case. > > And even with this fixed there are even larger problems, as you're > making access to structure members such as 'load_unacc_exec_time' > which only exist when CONFIG_FAIR_GROUP_SCHED is set, but you're doing > it in code that is built unconditionally. > > Please fix all of these build problems, as I want to test your changes > without all of the group scheduler bloat turned on. > > Thanks. >
| |