User: Password:
|
|
Subscribe / Log in / New account

This week in the scheduling discussion

This week in the scheduling discussion

Posted Apr 26, 2007 8:59 UTC (Thu) by nix (subscriber, #2304)
Parent article: This week in the scheduling discussion

This time-as-money analogy can be extended further. I can imagine a system which has a sort of futures market in runtime, where processes that will need runtime in the future can ask for it, costing some of its present runtime to do so and trading off against other processes which are asking for the same thing. (Asking for time at specific instants would cost more.)

This might be useful for things like multimedia apps that can tell that they have a bunch of especially hefty decoding work coming up in five seconds, or something like that.

(But I'm just babbling and have no code...)


(Log in to post comments)

This week in the scheduling discussion

Posted Apr 26, 2007 9:24 UTC (Thu) by nowster (subscriber, #67) [Link]

This time-as-money analogy can be extended further. I can imagine a system which has a sort of futures market in runtime...

Could a "rogue trader" break the bank? :-)

This week in the scheduling discussion

Posted Apr 27, 2007 14:11 UTC (Fri) by nix (subscriber, #2304) [Link]

I don't see how (assuming `breaking the bank' to equate to a DoS attack or something like that). If a process demands heaps of time in the future and doesn't use it, it'll sacrifice all its current time and end up with nothing (i.e. an idling system or other processes using the time instead). If it demands heaps of time and other things do as well, then it won't get that much time. No problem in either case.

HOWTO deny service

Posted Apr 30, 2007 5:55 UTC (Mon) by kbob (guest, #1770) [Link]

Consider an isochronous process like a real time audio processor.
It needs a time chunk every N milliseconds, so that's what it bids for.

A malicious process could outbid the audio process for a smaller timeslice
right when the audio app needs it. Then it could busy-loop for just
long enough that the audio app won't be able to finish on time.
Denial of Service.

On a longer time scale, the isochronous app might be a machine vision
system, a CD burner, or a monthly accounting report.

The malicious process wouldn't intentionally be malicious, of course.
It would just have an unfortunate self-scheduling policy.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds