![]() | ||||||||||
Messages in this thread |
On January 8, 2002 08:47 pm, Andrew Morton wrote: > Daniel Phillips wrote: > > What a preemptible kernel can do that a non-preemptible kernel can't is: > > reschedule exactly as often as necessary, instead of having lots of extra > > schedule points inserted all over the place, firing when *they* think the > > time is right, which may well be earlier than necessary. > > Nope. `if (current->need_resched)' -> the time is right (beyond right, > actually). Oops, sorry, right. The preemptible kernel can reschedule, on average, sooner than the scheduling-point kernel, which has to wait for a scheduling point to roll around. And while I'm enumerating differences, the preemptable kernel (in this incarnation) has a slight per-spinlock cost, while the non-preemptable kernel has the fixed cost of checking for rescheduling, at intervals throughout all 'interesting' kernel code, essentially all long-running loops. But by clever coding it's possible to finesse away almost all the overhead of those loop checks, so in the end, the non-preemptible low-latency patch has a slight efficiency advantage here, with emphasis on 'slight'. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:15 [from the cache] ©2003-2008 | ||||||||||