Date: Fri, 19 Aug 2011 13:28:19 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve Message-ID: <1156334334.20110819132819@serebryakov.spb.ru> In-Reply-To: <20110819092304.GB92576@zxy.spb.ru> References: <slrnj4oiiq.21rg.vadim_nuclight@kernblitz.nuclight.avtf.net> <810527321.20110819123700@serebryakov.spb.ru> <alpine.BSF.2.00.1108190939340.93669@fledge.watson.org> <20110819092304.GB92576@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Slawa. You wrote 19 =C1=D7=C7=D5=D3=D4=C1 2011 =C7., 13:23:04: >> There are a few known issues in terms of parallelism -- one is contention >> between the ithread and user thread on per-TCP connection locks. Anothe= r is=20 >> that we still haven't managed to switch to per-CPU statistics for the ne= twork=20 >> stack (which is fairly straight forward in a specific sense, but we'd li= ke a=20 >> proper abstraction for it so we can generalise). > After discussion in other place: may be perfomace improve if > application resheduling on the same core, as processing incoming > IP packet (hot CPU ca=D3he)? Yes, it is exactly what our admins done, and it helps, but if streams will grow (and they WILL) here will be a little space to grow up performance as well. But it is completely offtopic already. --=20 // Black Lion AKA Lev Serebryakov <lev@serebryakov.spb.ru>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1156334334.20110819132819>