On Wednesday, September 14, 2011 9:15:38 am Adrian Chadd wrote: > On 14 September 2011 19:40, John Baldwin <j...@freebsd.org> wrote: > > > You should probably commit that. I wonder if it should be a KASSERT() also > > so > > that it outright panics on a kernel with INVARIANTS enabled so developers > > will > > go fix their code as it seems to me to likely be a bug to enqueue a task > > that > > many times. > > Or maybe warn? If it's used per-interrupt (like say it is under ath, > but for a 10GE NIC doing a high packet rate) then you may end up > enqueuing the taskqueue quite often before it next gets a chance to > run. Otherwise the code will have to add some more locking and > tracking of its own to only enqueue the task once.
I think the real problem is the livelock case where the task just runs forever as opposed to the task not getting to run for a long time. However, if you set rx_processing_limit to -1 (or an equivalent knob) then you are basically asking for livelock. > As I said, I'm just worried that some of the taskqueue users are doing > some kind of poor mans refcounting where n(taskqueue_enqueue) > references has to equal the npending field in the taskqueue callback. Very few task routines actually use pending for anything. The ones that do are not likely to loop forever either. -- John Baldwin _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
