I tried to reply earlier, but it didn't show up(?) I apologize if this is a duplicate. Mulyadi Santosa wrote: >> I have to disagree with you about bad starvation. >> > Perhaps you read it incorrectly, I said "not just", not "not" > alone :) You are correct, I mis-read your statement. My apologies. >> The key difference is using tasklets leads to bounded (until the next >> tick) priority inversion, which should be acceptable for my >> application. >> > Although I agree tasklet has a chance to be executed sooner, I don't > really think we could assume it is guaranteed to run at least in the > next tick. In very busy machine such as highlu loaded web > servers, there > is a chance tasklets queued by the network interface's driver > wait for > several ticks. Perhaps what we need (I am not sure, maybe > it's already > implemented?) is "interrupt coalescing" in bottom half i.e 10 > interrupt shots are merged as one, thus CPU is just interrupted once. > Of course, > we must provide another data structure that define there are > 10 interrupts. So tasklet execution isn't necessarily (time) bound to the next tick... good to know, thank you! As far as the network example, it is my understanding that NAPI is trying to address exactly that concern, albiet in a different way. >> Workqueues lead to unbounded (until B relinquishes the CPU) priority >> inversion, which is not acceptable in my application. >> > There is indeed a crude solution for that :) Manually set keventd as > real time process too :) I have to admit this is pretty tempting. Is there any reason I could/should not just do this from an init/user process calling sched_setscheduler()? That seems the easiest way. I would prefer to use an existing documented API than potentially doing it the wrong way from within the kernel. >> I would love to see a tasklet_rt_schedule in addition to >> tasklet_schedule and tasklet_hi_schedule. >> > i see what you mean. Perhaps, tasklet_rt_schedule isn't > created because > kernel developers are afraid it is incorrectly used and leads to > starvation i.e you put lengthy operation inside, thus effectively > leaving other processes waiting for CPU. There are already so many ways to shoot your own foot off as a kernel developer, I would hope this reason would not preclude such an addition. Thank you again, Michael -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
