* Thomas Gleixner wrote:
> On Thu, 6 Apr 2017, Ingo Molnar wrote:
> > CPU hotplug and changing the affinity mask are the more complex cases,
> > because
> > there migrating or not migrating is a correctness issue:
> >
> > - CPU hotplug has to be aware of this anyway, regardless of whether it
On Thu, Apr 06, 2017 at 01:56:12PM +0200, Thomas Gleixner wrote:
> A pointer to the effective mask is definitely enough. And that's what we
> need for migrate_disable() as well. That still leaves the storage
> requirement to MIPS.
So then you're back to Ingo's proposal, right?
On Thu, 6 Apr 2017, Peter Zijlstra wrote:
> On Thu, Apr 06, 2017 at 01:03:16PM +0200, Thomas Gleixner wrote:
>
> > Fair enough, but I prefer to have the ability for a temporary restriction
> > of the user space visible cpus allowed mask in the core code, which can be
> > used for both migrate_disa
On Thu, Apr 06, 2017 at 01:03:16PM +0200, Thomas Gleixner wrote:
> Fair enough, but I prefer to have the ability for a temporary restriction
> of the user space visible cpus allowed mask in the core code, which can be
> used for both migrate_disable() and things like that MIPS FPU stuff rather
> t
On Thu, Apr 06, 2017 at 12:58:27PM +0200, Thomas Gleixner wrote:
> On Thu, 6 Apr 2017, Peter Zijlstra wrote:
> > Because mainline will not get anything other than prempt_disable() for
> > migrate_disable().
>
> I'm not yet convinced of that. There is enough stuff which pointlessly
> disables pree
On Thu, 6 Apr 2017, Ingo Molnar wrote:
> CPU hotplug and changing the affinity mask are the more complex cases,
> because
> there migrating or not migrating is a correctness issue:
>
> - CPU hotplug has to be aware of this anyway, regardless of whether it's
> solved
>via a counter of the
On Thu, 6 Apr 2017, Peter Zijlstra wrote:
> On Thu, Apr 06, 2017 at 12:47:21PM +0200, Thomas Gleixner wrote:
> > On Thu, 6 Apr 2017, Peter Zijlstra wrote:
>
> > > IIRC MIPS has a case where only 1 in N cores has an FPU. And once a task
> > > uses FPU, it gets affined to the core that has one or so
* Thomas Gleixner wrote:
> On Thu, 6 Apr 2017, Ingo Molnar wrote:
>
> > Sorry if this is a back and forth - I was somehow convinced that we do need
> > to
> > frob the cpus_allowed mask to get this functionality - but in hindsight I
> > think the counter should be enough.
> >
> > I.e. just h
On Thu, 6 Apr 2017, Peter Zijlstra wrote:
> On Thu, Apr 06, 2017 at 11:25:42AM +0200, Sebastian Andrzej Siewior wrote:
> > > I.e. just have a counter and these two APIs:
> > >
> > > static inline void migrate_disable(void)
> > > {
> > > current->migration_disabled++
On Thu, Apr 06, 2017 at 12:47:21PM +0200, Thomas Gleixner wrote:
> On Thu, 6 Apr 2017, Peter Zijlstra wrote:
> > IIRC MIPS has a case where only 1 in N cores has an FPU. And once a task
> > uses FPU, it gets affined to the core that has one or something like
> > that.
> >
> > Of course, nothing th
On Thu, 6 Apr 2017, Peter Zijlstra wrote:
> On Thu, Apr 06, 2017 at 11:46:33AM +0200, Sebastian Andrzej Siewior wrote:
> > On 2017-04-06 11:32:24 [+0200], Peter Zijlstra wrote:
> > > On Tue, Apr 04, 2017 at 08:42:02PM +0200, Sebastian Andrzej Siewior wrote:
> > > > While converting the existing use
On Thu, 6 Apr 2017, Ingo Molnar wrote:
> Sorry if this is a back and forth - I was somehow convinced that we do need
> to
> frob the cpus_allowed mask to get this functionality - but in hindsight I
> think
> the counter should be enough.
>
> I.e. just have a counter and these two APIs:
>
>
On Thu, Apr 06, 2017 at 11:46:33AM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-04-06 11:32:24 [+0200], Peter Zijlstra wrote:
> > On Tue, Apr 04, 2017 at 08:42:02PM +0200, Sebastian Andrzej Siewior wrote:
> > > While converting the existing users I tried to stick with the rules
> > > above how
On 2017-04-06 11:32:24 [+0200], Peter Zijlstra wrote:
> On Tue, Apr 04, 2017 at 08:42:02PM +0200, Sebastian Andrzej Siewior wrote:
> > While converting the existing users I tried to stick with the rules
> > above however… well mostly CPUFREQ tries to temporary switch the CPU
> > mask to do somethin
On Thu, Apr 06, 2017 at 11:25:42AM +0200, Sebastian Andrzej Siewior wrote:
> > I.e. just have a counter and these two APIs:
> >
> > static inline void migrate_disable(void)
> > {
> > current->migration_disabled++;
> plus
> if (current->migration_disabled == 1)
On Thu, Apr 06, 2017 at 11:35:45AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 06, 2017 at 10:01:39AM +0200, Ingo Molnar wrote:
> > I.e. just have a counter and these two APIs:
> >
> > static inline void migrate_disable(void)
> > {
> > current->migration_disabled++;
On Thu, Apr 06, 2017 at 10:01:39AM +0200, Ingo Molnar wrote:
> I.e. just have a counter and these two APIs:
>
> static inline void migrate_disable(void)
> {
> current->migration_disabled++;
> }
>
> ...
>
> static inline void migrate_enable(
On Wed, Apr 05, 2017 at 09:39:43AM +0200, Ingo Molnar wrote:
> > While converting the existing users I tried to stick with the rules
> > above however… well mostly CPUFREQ tries to temporary switch the CPU
> > mask to do something on a certain CPU and then switches the mask back it
> > its origina
On Tue, Apr 04, 2017 at 08:42:02PM +0200, Sebastian Andrzej Siewior wrote:
> While converting the existing users I tried to stick with the rules
> above however… well mostly CPUFREQ tries to temporary switch the CPU
> mask to do something on a certain CPU and then switches the mask back it
> its or
On 2017-04-06 10:01:39 [+0200], Ingo Molnar wrote:
>
> * Sebastian Andrzej Siewior wrote:
>
> > On 2017-04-06 08:16:22 [+0200], Ingo Molnar wrote:
> > >
> > > * Sebastian Andrzej Siewior wrote:
> > >
> > > > On 2017-04-05 09:39:43 [+0200], Ingo Molnar wrote:
> > > > >
> > > > > So maybe we c
* Sebastian Andrzej Siewior wrote:
> On 2017-04-06 08:16:22 [+0200], Ingo Molnar wrote:
> >
> > * Sebastian Andrzej Siewior wrote:
> >
> > > On 2017-04-05 09:39:43 [+0200], Ingo Molnar wrote:
> > > >
> > > > So maybe we could add the following facility:
> > > >
> > > > ptr = sched_m
On 2017-04-06 08:16:22 [+0200], Ingo Molnar wrote:
>
> * Sebastian Andrzej Siewior wrote:
>
> > On 2017-04-05 09:39:43 [+0200], Ingo Molnar wrote:
> > >
> > > So maybe we could add the following facility:
> > >
> > > ptr = sched_migrate_to_cpu_save(cpu);
> > >
> > > ...
> > >
> > > sch
* Sebastian Andrzej Siewior wrote:
> On 2017-04-05 09:39:43 [+0200], Ingo Molnar wrote:
> >
> > So maybe we could add the following facility:
> >
> > ptr = sched_migrate_to_cpu_save(cpu);
> >
> > ...
> >
> > sched_migrate_to_cpu_restore(ptr);
BTW., and I'm sure this has come up
On 2017-04-05 09:39:43 [+0200], Ingo Molnar wrote:
>
> So maybe we could add the following facility:
>
> ptr = sched_migrate_to_cpu_save(cpu);
>
> ...
>
> sched_migrate_to_cpu_restore(ptr);
>
> ... and use it in the cpufreq code. Then -rt could simply define
> migrate_disabl
* Sebastian Andrzej Siewior wrote:
> In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed()
> wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not
> much difference in !RT but in RT we used this to implement
> migrate_disable(). Within a migrate_disable() section
In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed()
wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not
much difference in !RT but in RT we used this to implement
migrate_disable(). Within a migrate_disable() section the CPU mask is
restricted to single CPU whil
26 matches
Mail list logo