LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Henrik Austad <henrik@austad.us>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org
Subject: Rearranging layout of code in the scheduler
Date: Tue, 28 Oct 2008 16:34:11 +0100	[thread overview]
Message-ID: <200810281634.11285.henrik@austad.us> (raw)

[-- Attachment #1: Type: text/plain, Size: 2602 bytes --]

Hello, 

Before I dive in, I should probably justify my motivations for writing
this email. I'm working away on implementing an EDF scheduler for real
time tasks in the kernel. This again leads to hacking at the existing
source as I'm not about to toss out the entire scheduler - just replace
(by some Kconfig switch) the RR/FIFO classes. As to why I'm looking at
EDF, I think the answer to that is a bit too long (and not appropriate
for this email anyway) so I'll leave that part out.

However, what I do mean to discuss is the current state of the scheduler
code. Working through the code, I must say I'm really impressed. The
code is clean, it is well thought out and the new approach with
sched_class and sched_entity makes it very modular. However, digging
deeper, I find myself turning more and more desperate, looking over my
shoulder for a way out.

Now, I'm in no doubt that the code *is* modular, that it *is* clean and
tidy, but coming from outside, it is not that easy to grasp it all. And,
it is not just the sheer size and complexity of the scheduler itself,
but also a lot with how the code is arranged.

For instance, functions like free_fair_sched_group,
alloc_fair_sched_group etc - does IMHO belong in sched_fair.c and not in
sched.c. The same goes for several rt-functions and structs.

So, if one drew up a list over all events that would cause functions in
sched.c to be called, this could be used to make a minimized 'interface'
and then let the scheduler call the appropriate function for the given
class in the same fashion sched_tick is used today. 

What I would like, is to rip out all the *actual* scheduling logic and
put this in sched_[fair|rt].c and let sched be purely event-driven
(which would be a nice design goal in itself). This would also lead to
sched_[fair|rt].h, where the structs, macros, defines etc can be
defined. Today these are defined in just about everywhere, making the
code unnecessary complicated (I'm not going to say messy since I'm not
*that* senior to kernel coding :-))

Why not use the sched_class for all that it's worth - make the different
classes implement a set of functions and let sched.c be oblivious to
what's going on other than turning the machinery around?

Is this something worth pursuing? I mean, the scheduler *does* work, and
if it ain't broken, don't fix it. However, I have a strong feeling that
this can be done a lot cleaner, not to mention, changing from one type
of scheduler to another will be much easier. :-)

-- 
med Vennlig Hilsen - Yours Sincerely
Henrik Austad

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

             reply	other threads:[~2008-10-28 16:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 15:34 Henrik Austad [this message]
2008-10-28 16:50 ` Peter Zijlstra
2008-10-28 19:41   ` Henrik Austad
2008-10-30 16:49   ` faggioli
2008-10-30 17:17     ` Deadline scheduling (was: Re: Rearranging layout of code in the scheduler) Peter Zijlstra
2008-10-30 17:48       ` Peter Zijlstra
2008-10-30 21:44       ` Henrik Austad
2008-10-31  9:03         ` Peter Zijlstra
2008-10-31 12:09           ` Henrik Austad
2008-10-31 13:30             ` Peter Zijlstra
2008-10-31 15:05               ` Henrik Austad
2008-10-31 18:08         ` Dario Faggioli
2008-10-31 17:49       ` Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200810281634.11285.henrik@austad.us \
    --to=henrik@austad.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --subject='Re: Rearranging layout of code in the scheduler' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).