Date: Fri, 19 Aug 2011 10:37:59 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Vadim Goncharov <vadim_nuclight@mail.ru>, Lev Serebryakov <lev@FreeBSD.org>, freebsd-arch@freebsd.org Subject: Re: FreeBSD problems and preliminary ways to solve Message-ID: <07024C3C-C6C7-47C1-9763-E3A62CA37B0C@FreeBSD.org> 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
On 19 Aug 2011, at 10:23, Slawa Olhovchenkov wrote: > On Fri, Aug 19, 2011 at 09:41:41AM +0100, Robert Watson wrote: >=20 >> There are a few known issues in terms of parallelism -- one is = contention=20 >> between the ithread and user thread on per-TCP connection locks. = Another is=20 >> that we still haven't managed to switch to per-CPU statistics for the = network=20 >> stack (which is fairly straight forward in a specific sense, but we'd = like a=20 >> proper abstraction for it so we can generalise). >=20 > 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)? We have a GSoC student working on this currently (measuring rough socket = affinity for applications a la RPS and redirecting work on the software = side). I also have some related work, which can supplement his, which = will push those application affinities into programmable TCAMs/hardware = hash tables in 10gbs cards. We do need some general improvements in = scheduling to allow the scheduler to take into account notions of = vertically aligning affinity, however. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07024C3C-C6C7-47C1-9763-E3A62CA37B0C>