Date: Tue, 4 Jan 2005 02:05:56 +0100 From: Stefan Bethke <stb@lassitu.de> To: "Youlin Feng" <yfeng@verniernetworks.com> Cc: freebsd-arch@freebsd.org Subject: Re: User process starvation in FreeBSD 5.3 Message-ID: <C9DC0288-5DEC-11D9-B067-000A95C893E4@lassitu.de> In-Reply-To: <12394E9FCB7C8441BB238D7F67B402E407E5C6@exch2.verniernetworks.com> References: <12394E9FCB7C8441BB238D7F67B402E407E5C6@exch2.verniernetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 03.01.2005 um 23:23 schrieb Youlin Feng: > We are building a network appliance running FreeBSD 5.3 and under very > heavy network traffic the user processes don't get scheduled for an > unacceptable period of time. Marking the user process/thread real-time > class doesn't help since the real-time user threads priorities are > still > lower than the interrupt threads. The effect you're describing very much sounds like 'livelock': the system is so overwhelmed with interrupts that it has no time to do anything else but servicing them. FreeBSD offers polling(4), which is intended to mitigate the overhead of a high interrupt rate on certain network controllers; especially in high-throughput scenarios, it can improve system load, throughput, and latency quite dramatically. On the other hand, your hardware might just not be able handle the packet rate. I'd suggest asking this on freebsd-net, where I believe quite a few people with experience in high-throughput setups are reading. Cheers, Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 170 346 0140
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C9DC0288-5DEC-11D9-B067-000A95C893E4>