Date: Fri, 18 Jan 2013 16:03:32 -0500 From: John Baldwin <jhb@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it>, Barney Cordoba <barney_cordoba@yahoo.com> Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Message-ID: <201301181603.32393.jhb@freebsd.org> In-Reply-To: <CAJ-VmokRFrFeK33_8a7ObapR7OXO730k2f-uBC_pgKmEqZw0uw@mail.gmail.com> References: <1358519440.88044.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301181149.42277.jhb@freebsd.org> <CAJ-VmokRFrFeK33_8a7ObapR7OXO730k2f-uBC_pgKmEqZw0uw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, January 18, 2013 3:07:35 pm Adrian Chadd wrote: > For my purposes, rescheduling the taskqueue means that other things > (such as TX, reset processing, other state handling, etc) can run > before the next pass at RX completion. That only works if your taskqueue thread has a priority <= those things. I think the e1000 drivers use the same priority for their taskqueue threads as the ithreads use, so the effectively preempt just about everything and are not preempted by other task queues or swi threads, etc. > Also, IIRC, acquiring mutexes are one of those magic points where the > scheduler may decide to switch things around in a preemption kernel. No, releasing mutexes (and any other place that makes a non-runnable thread runnable), and only if it wakes up a thread with a more important priority. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301181603.32393.jhb>