Date: Wed, 21 Nov 2012 10:11:11 +0100 From: Andre Oppermann <andre@freebsd.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Barney Cordoba <barney_cordoba@yahoo.com>, Adrian Chadd <adrian@freebsd.org>, khatfield@socllc.net, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Jim Thompson <jim@netgate.com>, Alfred Perlstein <bright@mu.org> Subject: Re: FreeBSD boxes as a 'router'... Message-ID: <50AC9AAF.8040705@freebsd.org> In-Reply-To: <CA%2BhQ2%2Bh8HHeO7xgjVJ0eZPtoOgYGbn-h3NWRSkYo6X8wh_hTmQ@mail.gmail.com> References: <1353448328.76219.YahooMailClassic@web121602.mail.ne1.yahoo.com> <E1F4816E-676C-4630-9FA1-817F737D007D@netgate.com> <50AC08EC.8070107@mu.org> <832757660.33924.1353460119408@238ae4dab3b4454b88aea4d9f7c372c1.nuevasync.com> <CAJ-Vmok8Ybdi%2BY8ZguMTKC7%2BF5=OxVDog27i4UgY-s3MCZkGcQ@mail.gmail.com> <250266404.35502.1353464214924@238ae4dab3b4454b88aea4d9f7c372c1.nuevasync.com> <50AC8393.3060001@freebsd.org> <CA%2BhQ2%2BiBLi%2B3_GAVBfiTMmiZPnqGRomXYABawPct4n7-Nrq2Ew@mail.gmail.com> <50AC92A0.2000406@freebsd.org> <CA%2BhQ2%2Bh8HHeO7xgjVJ0eZPtoOgYGbn-h3NWRSkYo6X8wh_hTmQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21.11.2012 09:53, Luigi Rizzo wrote: > On Wed, Nov 21, 2012 at 12:36 AM, Andre Oppermann <andre@freebsd.org> wrote: >> On 21.11.2012 09:04, Luigi Rizzo wrote: >> The only adjustment i'd suggest to your scheme, if possible, is to add >>> some control (as it existed in the old polling architecture) to make sure >>> that userspace is not starved by the ithreads and other kernel tasks >>> (otherwise you can have livelock, as it happens with NAPI). >>> I am afraid that simple priorities do not work, you either need some >>> kind of fair scheduler, or put some hard limit on the cpu fraction used >>> by the kernel tasks when there are userspace processes around. >>> >> >> That's the quantum stuff I talked about. When the ithread has used up >> its CPU quantum it gives up the CPU but schedules itself again at the >> same time. Also contrary to its name the ithread does not run in >> interrupt context but as a normal kernel thread with elevated priority. >> > > it is the elevated priority that worries me, because it has potential > to preempt userspace and cause livelock. > Again, lacking a proper fair process scheduler, i think the only reliable > way is > to try and track the (approximate) cpu cycles consumed overall by the > various ithreads over, say, the current tick, and once you go above > the threshold drop the priority of those threads just above IDLEPRI. > Then when the next tick arrives you raise the priorities again. That is what happens. The first time the ithread is scheduled it is run at high priority. When it yields after consuming its quantum it drops much lower but above heavily nice'd processes. Have to verify the exact level though. > Compared to when i did polling in 2000 (when i wanted to support the i486 > soekris), > now we can probably assume that a cheap timecounter is available on > all architectures (even ARM and MIPS should have some tsc-like thing, right > ?) > and the cycles used vs cycles per tick can be accounted with a relatively > fine grain. I hope to use as much existing kernel infrastructure as possible and to keep it simple. I certainly don't want to do cross-core load analysis. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50AC9AAF.8040705>