Messages in this thread | | | Subject | Re: [RFC][PATCH 17/22] sched: add signaling overrunning -deadline tasks. | From | Raistlin <> | Date | Fri, 12 Nov 2010 16:39:32 +0100 |
| |
On Thu, 2010-11-11 at 22:58 +0100, Peter Zijlstra wrote: > On Fri, 2010-10-29 at 08:40 +0200, Raistlin wrote: > > +static inline void __dl_signal(struct task_struct *tsk, int which) > > +{ > > + struct siginfo info; > > + long long amount = which == SF_SIG_DMISS ? tsk->dl.stats.last_dmiss : > > + tsk->dl.stats.last_rorun; > > + > > + info.si_signo = SIGXCPU; > > + info.si_errno = which; > > + info.si_code = SI_KERNEL; > > + info.si_pid = 0; > > + info.si_uid = 0; > > + info.si_value.sival_int = (int)amount; > > + > > + /* Correctly take the locks on task's sighand */ > > + __group_send_sig_info(SIGXCPU, &info, tsk); > > + /* Log what happened to dmesg */ > > + printk(KERN_INFO "SCHED_DEADLINE: 0x%4x by %Ld [ns] in %d (%s)\n", > > + which, amount, task_pid_nr(tsk), tsk->comm); > > +} > > This being a G-EDF like scheduler with a u<=1 schedulability test, we're > firmly in soft-rt territory which means the above will be very easy to > trigger.. Maybe not spam dmesg? > Ok, right. Maybe, if I add the SF_HARD_RT flag (and force the hard tasks to run on a single CPU they must specify) I can keep the notification for those tasks only. What do you think?
Thanks, 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@ekiga.net / dario.faggioli@jabber.org [unhandled content-type:application/pgp-signature] | |