![]() | |||||||||||||
Messages in this thread |
Petko Manolov writes: > Richard Gooch wrote:> > > > Petko Manolov writes:> > > I did a little different test on my pentium 166 MMX: > > >> > > kernel 2.0.35 5us> > > kernel 2.1.121 6us> > > kernel 2.1.122 6us - 7us> > > kernel 2.1.122 9us (under X Windows???)> > > > Did you run it as root? If you don't, the programme competes with X > > for time. Running it as root allows it to grab all the CPU it wants, > > and thus gives a more accurate test.> > Yes, i was root during all tests. OK, I think what this means is that under X you had more processes on the run queue. Since the scheduler has to scan the run queue, the longer it is the more time the scheduler takes. You can see the effect of this by using the <num_running> option: this will add the specified number of (low priority) processes to the run queue. Increasing this number will slow the scheduler down. In fact, this indicates that Linux only maintains a single run queue. It could be argued that for RT performance, we'd be better off with two run queues: one for SCHED_OTHER and the other for RT scheduling classes. This way scheduling times for RT processes would not be affected by the number of normal processes on the run queue. However, it could be counter-argued that there are not usually many processes on the run queue anyway. This is likely true for embedded systems, but isn't necessarily the case for a large system controlling an instrument as well as supporting users [1]. Another possible advantage of separating the run queue would be that it would then become cheap to *always* call schedule() (or perhaps schedule_rt()) upon return from interrupt/syscall. In most cases there won't be any RT processes on the run queue, so this would only add a few cycles overhead to the scheduler. The advantage of doing this is that RT processes which are woken up by a driver will preempt whatever is currently running, and hence will actually start running immediately, rather than waiting N jiffies. This would make Linux more RT-friendly. Linus: what do you think of this idea? A valid project for 2.3? I have to say I'm impressed with the soft-RT performance of Linux. In my view the main limitation is the jiffies delay between when an RT process is unblocked and when it starts running. > But i thought that software switch is faster than hardware. Not always. See Linus' message about this. > Other point is if this times can be correctly computed from user > level? We have a pretty accurate gettimeofday(2) syscall, which makes doing this easy. Particularly on the Pentium and above, where we use the TSC for greater accuracy. I'm not sure how good it is on the 486 and lower. In any case, in my code I'm careful to amortise the cost of getting the time and reducing the inaccuracies of the timestamp by running through the scheduler in a loop. Regards, Richard.... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:44 [from the cache] ©2003-2008 | |||||||||||||