I think what you see is that when your wait expires, you will be scheduled within the next 1/1000 sec ( in reality when the clock tick happens, the scheduler looks at the expired timers, and reschedules ). So if your timer expires at the beginning of a clock cycle, you may have to wait to the next clock tick for the next opportunityto run.
But all this is a function of the scheduler, and all of the enhancements than can be made in the guise of one application efficiency. A compute bound job may not like to have its quanta given up. a heavy service bound program may want to be waken as soon as possible to continue its mission. I think that you will notice 1000hz on a 75mhz machine. Its probably less noticeable on a newer 1gHZ machine. So I suppose this depends on the evolutionary point of processors that you want to try this on. Maybe Linux needs a scheduler module? Btw On an Alpha computer, the clock tic is set at 1000hz by the SRM ( bios to intel folks ) . Thats a lot of interrupts ( for a 233mhz RISC single processor) , and I wanted to set it to 100hz ( like intel ). So I changed the kernel, but was unable to get the SRM to change. Nowadays there is less of a reason to change the 1000hz setting. > Jim Hazen wrote: > > That's a good point. However on my Dual 450 there seems to be no > performance loss with these new settings. In fact things seem a bit > more responsive. I'm not sure exactly why, but my guess would be > extensive use of 'wait and notify' in various programs. Before there > was a 10ms penalty if one wanted to use this mechanism, now there > isn't (but with the risk of many more context switches). My experience > seems to indicate that this penalty outweighs the savings of fewer > switches. > > -Jim > > The downside for sure it that you now interrupt the cpu 1000 times per > second. The overhead in processing the interrupt. ( context save, > registers saved ). The services performed at a clock ( jiffy ) tick ( > timeout services, scheduling services ), are now done more frequently. > but with 1 gighz machine, 1/1000sec is ~1million instructions before an > jiffy happens. So if your threads complete before the million, then u r > in great shape. If they take longer, then that task may be scheduled out > to some other task that is also ready to run. I am not sure if a > Threaded task total quantum(s) are include in scheduling priority, or > each thread has their own unique scheduling priority. > > /gat > > BTW rumor has it ( from the Dec Alpha folks ) that context switching is > not very efficient on intel processors. ---------------------------------------------------------------------- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
