On 2020-10-02 16:21:49 [+0200], Peter Zijlstra wrote:
> Yeah, I didn't want it in a header where world can access it and attempt
> creative use :/
tell me about it. Currently cleaning up other creative abuse of things…
Sebastian
On Fri, Sep 25, 2020 at 06:50:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-09-21 18:36:04 [+0200], Peter Zijlstra wrote:
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -1700,6 +1700,68 @@ void check_preempt_curr(struct rq *rq, s
> >
> > #ifdef CONFIG_SMP
> >
> > +
On 2020-09-21 18:36:04 [+0200], Peter Zijlstra wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1700,6 +1700,68 @@ void check_preempt_curr(struct rq *rq, s
>
> #ifdef CONFIG_SMP
>
> +#ifdef CONFIG_PREEMPT_RT
…
> +static inline bool is_migration_disabled(struct task_struct *
On Thu, Sep 24, 2020 at 12:53:25PM +0100, Valentin Schneider wrote:
> > @@ -1830,8 +1892,19 @@ static int migration_cpu_stop(void *data
> > */
> > void set_cpus_allowed_common(struct task_struct *p, const struct cpumask
> > *new_mask, u32 flags)
> > {
> > - cpumask_copy(&p->cpus_mask, new_ma
On 24/09/20 13:29, Peter Zijlstra wrote:
> On Thu, Sep 24, 2020 at 12:53:25PM +0100, Valentin Schneider wrote:
>> On 21/09/20 17:36, Peter Zijlstra wrote:
>>
>> [...]
>>
>> > +void migrate_enable(void)
>> > +{
>> > + if (--current->migration_disabled)
>> > + return;
>> > +
>> > + barri
On Thu, Sep 24, 2020 at 12:53:25PM +0100, Valentin Schneider wrote:
> On 21/09/20 17:36, Peter Zijlstra wrote:
>
> [...]
>
> > +void migrate_enable(void)
> > +{
> > + if (--current->migration_disabled)
> > + return;
> > +
> > + barrier();
> > +
> > + if (p->cpus_ptr == &p->cpus_ma
Still trying to digest 8/9, but have some comments before I next get
preempted :)
On 21/09/20 17:36, Peter Zijlstra wrote:
[...]
> +void migrate_enable(void)
> +{
> + if (--current->migration_disabled)
> + return;
> +
> + barrier();
> +
> + if (p->cpus_ptr == &p->cpus_m
On 9/23/20 7:08 PM, pet...@infradead.org wrote:
> On Wed, Sep 23, 2020 at 10:31:10AM +0200, Thomas Gleixner wrote:
>>In practice migrate disable could be taken into account on placement
>>decisions, but yes we don't have anything like that at the moment.
> I think at the very least we shoul
On Wed, Sep 23, 2020 at 10:31:10AM +0200, Thomas Gleixner wrote:
>In practice migrate disable could be taken into account on placement
>decisions, but yes we don't have anything like that at the moment.
I think at the very least we should do some of that.
The premise is wanting to run the
On 9/23/20 10:31 AM, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 22:42, Daniel Bristot de Oliveira wrote:
>> On 9/21/20 9:16 PM, Thomas Gleixner wrote:
>>> On Mon, Sep 21 2020 at 18:36, Peter Zijlstra wrote:
>>> But seriously, I completely understand your concern vs. schedulability
>>> theories
On Mon, Sep 21 2020 at 22:42, Daniel Bristot de Oliveira wrote:
> On 9/21/20 9:16 PM, Thomas Gleixner wrote:
>> On Mon, Sep 21 2020 at 18:36, Peter Zijlstra wrote:
>> But seriously, I completely understand your concern vs. schedulability
>> theories, but those theories can neither deal well with pr
On Mon, Sep 21, 2020 at 09:16:54PM +0200, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 18:36, Peter Zijlstra wrote:
> > +/*
> > + * Migrate-Disable and why it is (strongly) undesired.
> > + *
> > + * The premise of the Real-Time schedulers we have on Linux
> > + * (SCHED_FIFO/SCHED_DEADLINE) is
On 9/21/20 9:16 PM, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 18:36, Peter Zijlstra wrote:
>> Add the base migrate_disable() support (under protest).
>
> :)
>
>> +/*
>> + * Migrate-Disable and why it is (strongly) undesired.
>> + *
>> + * The premise of the Real-Time schedulers we have on L
On Mon, Sep 21 2020 at 18:36, Peter Zijlstra wrote:
> Add the base migrate_disable() support (under protest).
:)
> +/*
> + * Migrate-Disable and why it is (strongly) undesired.
> + *
> + * The premise of the Real-Time schedulers we have on Linux
> + * (SCHED_FIFO/SCHED_DEADLINE) is that M CPUs ca
Add the base migrate_disable() support (under protest).
While migrate_disable() is (currently) required for PREEMPT_RT, it is
also one of the biggest flaws in the system.
Notably this is just the base implementation, it is broken vs
sched_setaffinity() and hotplug, both solved in additional patch
15 matches
Mail list logo