linux-kernel - scheduler code and task

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>] [day] [month] [year] [list]

Message-ID: <4b6fba110807200938l5c210687j3910ca67acf887ca@mail.gmail.com>
Date:	Sun, 20 Jul 2008 12:38:36 -0400
From:	"Daniel Rosenthal" <danielrosenthal@....org>
To:	linux-kernel@...r.kernel.org
Subject: scheduler code and task_struct

I'm implementing a process scheduling algorithm (Sporadic Server,
SCHED_SPORADIC in POSIX) and there is some algorithm specific
per-process information that I have to maintain somewhere.  Also, the
algorithm must take more (per-process) parameters than just the int
sched_priority parameter in sched_param.  It looks like the most
appropriate place to put this information is in task_struct, this kind
of looseleaf information clutters it up.  Where should this
information go?  It seems like this dilemma affects more than just
this specific algorithm, but it would affect any more sophisticated
algorithms in the future which make use of more than just a priority
parameter and a timeslice for the currently running task.

What I've done so far is add a struct __sched_settings and struct
__sched_state to task_struct, which could be used by any scheduler
(both of these should perhaps be unions instead).  I've also added an
event queue to every runqueue that gets triggered on scheduler_tick()
and hrtick() since the algorithm has to maintain a list of execution
capacity replenishment events that are always scheduled to happen in
the future.  I'm not sure either of these are the most general or
extensible solution.  Any ideas (not just specifically for this
algorithm, but to provide more robust generic facilities for new
scheduling algorithms in the future)?

Please CC me personally in any replies because I'm not subscribed to
the mailing list.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/