Date: Fri, 2 Mar 2007 09:37:29 -0500 From: "Keith Arner" <vornum@gmail.com> To: "Attilio Rao" <attilio@freebsd.org> Cc: freebsd-smp@freebsd.org Subject: Re: INP_INFO_WLOCK(&tcbinfo) bottleneck Message-ID: <8e552a500703020637l2e1d6036h4a975736bdc48914@mail.gmail.com> In-Reply-To: <3bbf2fe10703011211i6b0ad2b6gf75067ca17d0ac3b@mail.gmail.com> References: <8e552a500703010645x61d9b064w21c475ecc00a0e0e@mail.gmail.com> <3bbf2fe10703011211i6b0ad2b6gf75067ca17d0ac3b@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 3/1/07, Attilio Rao <attilio@freebsd.org> wrote: > > > Currently, the main problem for this is that somewhere (TM) there > mutex gets recursed and recursion is not handled alredy for rwlocks, > so kernel starts panicing. > > Patch for recursion in rwlock is not trivial, but there are ongoing > discussions on it. > Well, even if the INP_INFO_[RW]LOCK macros were changed to use shared/exclusive locks rather than a mutex, and the sx locks were fixed to be taken recursively, I'm not sure that would really do the trick for parallelism. In tcp_input(), the code is using INP_INFO_WLOCK(), to take an exclusive lock, so only one thread would be able to be in the TCP input code path anyway. Keithhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8e552a500703020637l2e1d6036h4a975736bdc48914>