Re: [patch 5/5] sched: consolidate sbe sbf

* Nick Piggin <[EMAIL PROTECTED]> wrote: > We could just do a set_cpus_allowed, or take the lock, > set_cpus_allowed, and take the new lock, but that's probably a bit > heavy if we can avoid it. In the interests of speed in this fast path, > do you think we can do this in sched_fork, before

Re: [patch 5/5] sched: consolidate sbe sbf

* Nick Piggin <[EMAIL PROTECTED]> wrote: > Nick Piggin wrote: > > > > >One problem I just noticed, sorry. This is doing set_cpus_allowed > >without holding the runqueue lock and without checking the hard > >affinity mask either. > > > > Err, that is to say set_task_cpu, not set_cpus_allowed.

Re: [patch 5/5] sched: consolidate sbe sbf

* Nick Piggin [EMAIL PROTECTED] wrote: Nick Piggin wrote: One problem I just noticed, sorry. This is doing set_cpus_allowed without holding the runqueue lock and without checking the hard affinity mask either. Err, that is to say set_task_cpu, not set_cpus_allowed. yes. The whole

Re: [patch 5/5] sched: consolidate sbe sbf

* Nick Piggin [EMAIL PROTECTED] wrote: We could just do a set_cpus_allowed, or take the lock, set_cpus_allowed, and take the new lock, but that's probably a bit heavy if we can avoid it. In the interests of speed in this fast path, do you think we can do this in sched_fork, before the

Re: [patch 5/5] sched: consolidate sbe sbf

Nick Piggin wrote: One problem I just noticed, sorry. This is doing set_cpus_allowed without holding the runqueue lock and without checking the hard affinity mask either. Err, that is to say set_task_cpu, not set_cpus_allowed. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the

Re: [patch 5/5] sched: consolidate sbe sbf

Ingo Molnar wrote: * Nick Piggin <[EMAIL PROTECTED]> wrote: 5/5 Any ideas about what to do with schedstats? Do we really need balance on exec and fork as seperate statistics? Consolidate balance-on-exec with balance-on-fork. This is made easy by the sched-domains RCU patches. As well as the

Re: [patch 5/5] sched: consolidate sbe sbf

* Nick Piggin <[EMAIL PROTECTED]> wrote: > 5/5 > > Any ideas about what to do with schedstats? > Do we really need balance on exec and fork as seperate > statistics? > Consolidate balance-on-exec with balance-on-fork. This is made easy > by the sched-domains RCU patches. > > As well as the

Re: [patch 5/5] sched: consolidate sbe sbf

* Nick Piggin [EMAIL PROTECTED] wrote: 5/5 Any ideas about what to do with schedstats? Do we really need balance on exec and fork as seperate statistics? Consolidate balance-on-exec with balance-on-fork. This is made easy by the sched-domains RCU patches. As well as the general

Re: [patch 5/5] sched: consolidate sbe sbf

Ingo Molnar wrote: * Nick Piggin [EMAIL PROTECTED] wrote: 5/5 Any ideas about what to do with schedstats? Do we really need balance on exec and fork as seperate statistics? Consolidate balance-on-exec with balance-on-fork. This is made easy by the sched-domains RCU patches. As well as the

Re: [patch 5/5] sched: consolidate sbe sbf

Nick Piggin wrote: One problem I just noticed, sorry. This is doing set_cpus_allowed without holding the runqueue lock and without checking the hard affinity mask either. Err, that is to say set_task_cpu, not set_cpus_allowed. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the

[patch 5/5] sched: consolidate sbe sbf

5/5 Any ideas about what to do with schedstats? Do we really need balance on exec and fork as seperate statistics? Consolidate balance-on-exec with balance-on-fork. This is made easy by the sched-domains RCU patches. As well as the general goodness of code reduction, this allows the runqueues to

[patch 5/5] sched: consolidate sbe sbf

5/5 Any ideas about what to do with schedstats? Do we really need balance on exec and fork as seperate statistics? Consolidate balance-on-exec with balance-on-fork. This is made easy by the sched-domains RCU patches. As well as the general goodness of code reduction, this allows the runqueues to