Re: Terminate and Stay Resident Software (TSR) in Linux
Hello,
Your program would just wait for input. The process running your
program would then not be scheduled until some input comes.
Do you mean it is not running at all if no input comes through?
I thought every process gets at least a time slice every now and then.
Is this assumption thereby wrong?
In my opinion a process which waits would react to a time slice with
something like "Oh, I've got nothing to do, scheduler, switch to your next
process".
If waiting from incoming connections, use listen, from incoming
data from a socket use recv... and so on.
You mean blocking calls interfere with the low-level scheduler so that the
program simply don't get cpu time?
Regards,
Sebastian
.
Relevant Pages
- Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
... But anyway, based on the evidence, I think the problem is caused by the fact that the eatm tasks are running to completion in less than one time slice without sleeping and this means that they never have their priorities reassessed. ... The reason that it does this is that it gives newly forked processes a fairly high priority and if they're left to run for a full 120 msecs at that high priority they can hose the system. ... Having a shorter first time slice gives the scheduler a chance to reassess the task's priority before it does much damage. ...
(Linux-Kernel) - Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
(Linux-Kernel) - Re: Blocking read() policy?
... >> It doesn't require any particular advanced scheduler. ... Especially if pgms demanding short latency ... that a CPU intensive process would ... starts over with the shortest possible time slice. ...
(comp.os.linux.development.system) - Which Kernel for soft realtime on ARM 9
... The most critical area for that effect was detected to be the Oscheduler that uses much more code than the 2.4 Oscheduler, while with only some 10-20 processes the Oscheduler is not faster than the Oversion. ... Moreover the higher time slice scheduling rate of 1 instead of 10 msec results in unnecessarily increased overhead. ... I did some tests with that and I found that the patch does not help much, when the IDE driver is used for a non-realtime process that runs concurrently with a high priority realtime process. ... The embedded ARM project will not do too much IDE driver work, so maybe the Kernel preemption patch might do a better job here, but a compact flash drive is planned be included and used sporadically. ...
(comp.os.linux.embedded) - Re: [NT] Quantum of interrupted process
... operating systems. ... I believe a thread is not handed a time slice ... I believe any interruption time that a thread ... will the scheduler switch to P3 with Q3 ...
(microsoft.public.development.device.drivers) |
|
