OSDev.org

Hi,

ashishkumar4 wrote:ok I finally got all this. But now I am in trouble :/ now how to make a good scheduler? I don't have any more ideas :/ means neither round robins nor lottery scheduling seems to fulfill the requirements. Please help me make a good algorithm. Thanks

Different tasks have different characteristics, so start by writing a list of "important characteristics". Note that this will depend on the nature of your OS and what it's designed for. For "micro-kernel with synchronous message passing" you might be expecting a lot of tasks that wait for a message, do very little, then send a reply. For "micro-kernel with asynchronous message passing" you might postpone task switches so that tasks handle many messages and send many replies. For "real time OS" you might have very different requirements. For "monolithic OS designed for HPC" you might want something very different to "monolithic OS designed for web servers".

You might find that (especially for a general purpose OS) you have some very different characteristics involved. Most general purpose OSs have multiple different scheduling policies (with completely different scheduling algorithms for different scheduling policies) for this reason. For example, you might have something designed specifically for real-time tasks, something designed for specifically for high priority interactive tasks, something designed specifically for batch processing, something designed specifically for idle threads, etc.

With multiple scheduling policies you end up with a kind of 'meta scheduler" - something to determine which scheduling policy (plus different schedulers for each scheduling policy).

"A good algorithm" can be "many good algorithms".


Cheers,

Brendan

I think the reason is this:
After every interrupt handling is over, at the last of it, the code goes like
sti;
iret;

It can be that if the scheduler gets long enough, another interrupt may get fired while previous one was being handled. Now that wont affect me as I used cli, sti. but as soon as I do 'sti' I think the next interrupt gets fired and the function is not being able to return from the previous interrupt via iret. That's my theory I don't know is right or wrong but that's the only point were I think things can go wrong. and by Murphy's law, things may be going wrong indeed

ashishkumar4 wrote:I think the reason is this:
After every interrupt handling is over, at the last of it, the code goes like
sti;
iret;

You sure about putting that sti there? IRET / IRETD

IRET pops CS EIP and EFLAGS

I don't get what you meant by "you sure about putting sti there". means where to put it ? and yeah I know iret does that.

You don't need to put a STI. The IRET instruction restores your interrupt state.

without that it dosent even work :/ not at all :/ wait let me try again

Then you have another problem, you should not need to do CLI or STI in your interrupt handler for the scheduler. You can setup your IDT to do that automatically for you (Research the difference between a Trap Gate and Interrupt Gate).

o.O ohk