linux-kernel - Re: [RFC][PATCH] SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1253708392.5631.408.camel@Palantir>
Date:	Wed, 23 Sep 2009 14:19:52 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	claudio@...dence.eu.com, michael@...dence.eu.com, mingo@...e.hu,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	johan.eker@...csson.com, p.faure@...tech.ch,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Subject: Re: [RFC][PATCH] SCHED_EDF scheduling class

On Tue, 2009-09-22 at 20:36 +0200, Peter Zijlstra wrote:
> > The, let's say, proper task period is left to the userspace, i.e.,
> > suspending until the next period/sporadic activation is not done in the
> > kernel, it is up to the task.
> > This is the most flexible interface we have been able to design, while
> > trying to reduce the amount of information that has to be added to the
> > minimum... Different ideas are more than welcome. :-)
> 
> No bright ideas at the moment, but it might be worth-while to describe
> this task model somewhere near sched_param_ex :-)
>
Well, when you have a good point... You have a good point! :-D

> > Well, I think it might be possible, if rt is bandwidth constrained, as
> > it is/it is becoming... Don't you?
> 
> Ah, the problem I see there is that your minimum deadline gets
> constrained by whatever you configure your SCHED_FIFO bit to, this
> doesn't seem ideal.
> 
Agree again, not the ideal behaviour... However, as said, I would like
to experiment some more on this, and to (re)read the papers where they
introduces the analysis for EDF-under-RM. :-)

However, I should start thinking moving it upward, should I?

> I would argue that kstopmachine is going to break pretty much
> everything, so a workload that contains one (module unload, cpu-hotplug)
> will not be analyzable. 
>
Ok, I think most of the people can stand this! :-P

> I'd rather say that anything kstopmachine will violate RT guarantees.
> 
> As to migrate, I think we can model that as a regular non-preempt
> section (we could actually remove the migrate thread and actually make
> it such). 
> 
I see... and do you think one more scheduling class would be needed, or
something like 0 deadline would do the trick?

> > This may be suboptimal and rise at least overhead, clock synchronization
> > and locking issue, but I hope, again, it could be a start... A (bad?)
> > solution to compare against, when designing better implementations, at
> > least.
> 
> Agreed, its a pragmatic starting point, and only by implementing it can
> we evaluate it.
> 
Hope it will be ready soon...

> > Another thing I would like to have, is a task receiving a SIGXCPU if it
> > misses its deadline, which might happen actually, e.g., if you load an
> > UP system/a CPU more than 100% with EDF tasks.
> 
> Missing a deadline, and possibly over-running a deadline too.
> 
> Maybe add a flags field to the sched_param_ex thing ;-)
> 
Could be done as well... What do you mean by over-running a deadline?

By missing, I mean that at a certain instant t, typically during a
(hr)tick I notice that the scheduling deadline d is <= t, which means we
probably are in overload condition, is that the same? Just to
understand... :-)

> > At the current time, I'm just splitting the bandwidth, and nothing more.
> > Actually, I also think the solution is the right one, but I would really
> > like to discuss the issues it raises.
> 
> Ooh, good point,.. yes we can put some exit hooks in there folding the
> runtime back.
> 
> An alternative is starting the child out with 0 runtime, and have the
> parent run sched_setscheduler() on it giving us a clear point to run
> admission on.
> 
I thought this too, we just have to chose whether the 'more natural' or,
let's say 'user friendly', behaviour is...

Thanks again for the comments.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)