Minimalist Microkernel Memory Management

[gaf]

About the policies: None of those are necessary when applications can schedule themselves.

Some of the policies I've enumerated have properties that may be very usefull for certain apps: Priority round-robin for example can improve responsiveness and the earliest-deadline-first algorithm can be usefull in real-time systems that need a better flexibility. In my opinion most applications will actually run using an external scheduler rather than the Xok mechanism.

About Bush: That comment is off-topic and below-the-belt.

My intention was to provoke, not to insult and I'm sorry if I have crossed the line. The thing is that I was a bit surpised/shocked about your attitude towards common-sense and "hard" numbers so that I wanted to know your reasons and you have to agree that my strategy has worked out . What I didn't expect is that you'd take my sentence as an insult, especially as you've also made some rather debatable statements in the past that I could have have taken personally if I wanted to.

It's hubris to think you can immediately do better than people who have worked on it more and have far more experience than you based on nothing more than your "common sense."

As it's hardly ever meant that way I don't take such things personally and my policy is that everybody that makes such statements (including myself) should also be able to take them..

About a variably-sized vector: The whole point of doing it in some multiple is so that you can proportionally expand the timeslices to multiple timeslices in the new vector. Timing would still be guaranteed.

When you mentioned this some posts ago, I at first also thought that it might work, but "propertionally" unfortunately isn't enought in this case. Let's say that there are in total 100 time-slices in the system which are held by three task (20, 50, 30 in blocks for simplicity). If you now increase the total number of time-slices by 2 and update the number of time-slices accordingly, the tasks still hold the same share of the CPU, but the time for which they run and their periode have doubled so that the real-time advantage is lost.

regards,
gaf

[QuiTeVexat]

Some of the policies I've enumerated have properties that may be very usefull for certain apps: Priority round-robin for example can improve responsiveness and the earliest-deadline-first algorithm can be usefull in real-time systems that need a better flexibility.

Improving responsiveness is an issue of introducing preemption, and realtime I think I already addressed in an earlier post.

My intention was to provoke, not to insult and I'm sorry if I have crossed the line.

Ahhh, so you were saying that numbers could show things either way depending on the reader? Alright.

Edit: I misinterpreted. Sorry. Now I feel dumb. See what you've done?!?!

The thing is that I was a bit surpised/shocked about your attitude towards common-sense and "hard" numbers so that I wanted to know your reasons and you have to agree that my strategy has worked out

Eh? It has? Good job, it was stealthy too, cause I'm none-the-wiser. My issue is that hard numbers and experience *do* tell more than "common sense". I think some things really don't leave as much up to interpretation, especially if you define what you're looking for. If one machine routes 50 Mbps, and another 100 Mbps, those numbers tell me which routes faster any way you read it. Then again, there are other factors, like reliability. But I'd want some numbers on that, too, as well as the experience that tells me which really works better in practice. My common sense doesn't tell me these things.

What I didn't expect is that you'd take my sentence as an insult, especially as you've also made some rather debatable statements in the past that I could have have taken personally if I wanted to.

Sorry for any insults I've thrown. Wasn't meaning to.

As it's hardly ever meant that way I don't take such things personally and my policy is that everybody that makes such statements (including myself) should also be able to take them..

Yea, mine was probably a bit inflammatory. Although the implication of "you're being arrogant" is lesser than what I got from your sentence, so before I realized what you actually meant, it occurred to me as much nastier than anything we'd been doing previously.

About the variably-sized-vector: I wasn't suggesting multiplying the total amount of time, just splitting up the timeslices inside it. So we're representing the same amount of time, just with smaller pieces.

Pax tecum,
Qui te vexat.

[Colonel Kernel]

About the variably-sized-vector: I wasn't suggesting multiplying the total amount of time, just splitting up the timeslices inside it. So we're representing the same amount of time, just with smaller pieces.

I thought that each timeslice was already the length of one clock tick... so how can you sub-divide them...?

[QuiTeVexat]

Reprogram the PIT, or whatever you're using. I don't think you'd really need to change the vector-length anyway though.

P.S.: A thought: if you wanted to expand the time it took up, you could just multiply and then copy the current allocations over into their future positions. But then again, you need to ensure proper notification or apps could have some issues. As above, I don't think you'd really need to do this anyway.

P.P.S.: I've also been considering a system with an ordered list of variable slices arranged sorta like a delta-queue. Which would allow for the same when/how much thing, while giving more precision and reducing timer overhead. I dunno, just a thought. Of course, this might have been how they intended the system anyway, use ranges referring to absolute values in a vector. Hm. Ignore this.