Profiling

[dc0d32]

wouldn't it be nice if i could somehow (dont know exactly how) profile each thread or atleast each task for a few first runs, store it's behaviour data, and use that data to schedule resources in future?

i mean, when you click the burn button of a cd recorder app, the app will make a hell lot of syscalls, and/or memory usage. if i could somehow store the probable future requirements after a specific event, and i could calculate the probability of the event itself, i can better do the predictive resource scheduling.

problem is, how to profile such data, the event thing looks manageable, and how to store it, use it effectively without or with less mispredictions? has someone done such things before? is this something called as "resource based scheduling" done in RTOS?

[Human]

what do you exactly mean by "storing information"? what inf? how will u record it? Profiling is not exactly what you are talking. AFAIK, it is just seeing which section of code executes for what % of total processor usage by the app.

[Pype.Clicker]

well, i'm not so sure burning a CDROM needs that much RAM ... it certainly needs plenty of disk accesses (and well, yes, maybe it might need RAM to hold files that are to small to be accessed in time).

But the RAM it needs can be calculated as it is needed, its usage will depend on the actual CD to be burn (with videos, you might even don't need RAM).

And, imho, the biggest problem in that case will be scheduling I/O accesses (e.g. giving priority to the burning process over e.g. browser cache access ...), or notifying the system that a time-critical operation is pending and that it wouldn't be a Wise Thing (tm) to start document indexing or defragmentation or OS update stuff right now ...

[Solar]

Well, in a way what you are describing here, prashant, is a dynamic priority scheduler.

Basically, you have tasks that are either computation-intensive or I/O intensive. The former use up their timeslices more often than not, crunching numbers. The latter usually make some system call before their timeslice expires.

So, whenever a timeslice expires without a system call being made, you adapt the priority of the process. Whether you increase or decrease the priority depends on what you want to achieve, and is open for discussion.

I can't picture rigth nwo how this could be expanded to e.g. memory requirements (either the memory is there or it isn't) or network bandwidth, but it is surely possible. Just don't start to generate a large-ish database on X different parameters, or you'll lose more time in collecting and administrating the data than you could win by improving the scheduling.

As for RTOS, it doesn't help to know the probable ressource usage. If you want to do hard real-time, you have to know the exact ressource usage in order to do the magic "guaranteed success" thing.

[dc0d32]

hmm.

lets consider that for only memory then, for time being. Am i thinking on the lines of optimal page replacement algo...

BTW, the CD burning was just an example, wasn't perfect in this situation i should admit.