On 3/17/08, Peter Teoh <[EMAIL PROTECTED]> wrote: > Looking at schedule_work() below: > > fs/file.c: > > fddef = &get_cpu_var(fdtable_defer_list); > spin_lock(&fddef->lock); > fdt->next = fddef->next; > fddef->next = fdt; > /* vmallocs are handled from the workqueue context */ > schedule_work(&fddef->wq);===> > spin_unlock(&fddef->lock); > > can schedule_work() sleep? if so, then holding a spin_lock (which is > supposed to be used for quick turnaround operation) across a sleepable > functions look risky here (though it is possible to design this way, > but the classic CPU 100% bug is possible - sleep and never wake up, > resulting in another CPU going into spin_lock mode - churning up 100% > CPU time). Or may be I am wrong? > > Can calling this function schedule_work() ever ended the entire task > being reassigned to another CPU? If so, then, will it not defeats > the purpose of using the per_cpu function get_cpu_var()? > > How about schedule() -->ever ended the entire task being reassigned to > another CPU? ? >
Hey Peter, btw. have you found out whether or not a "spin_lock" after "get_cpu_var" makes sense. I couldn't understand it either. Arvin -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
