Date: Sat, 7 Jun 2014 20:26:37 +0100 From: Igor Mozolevsky <igor@hybrid-lab.co.uk> To: Adrian Chadd <adrian@freebsd.org> Cc: Hackers freeBSD <freebsd-hackers@freebsd.org>, Daniel Janzon <janzon@gmail.com>, Dirk Engling <erdgeist@erdgeist.org>, Ian Lepore <ian@freebsd.org> Subject: Re: Best practice for accepting TCP connections on multicore? Message-ID: <CADWvR2getzzd8we%2BYSQS6vq-7kJn2j-3WhQxWQAP9O8GNLWZOQ@mail.gmail.com> In-Reply-To: <CAJ-Vmom=QOZtn1jQADPZfV10TXD4aoNQT7jhip_sp_=zQ04jog@mail.gmail.com> References: <CAAGHsvDhaqQbwir5P%2BoaH_Qa8VZ0aj9A2SGrn%2B2shJMQ21B6Jw@mail.gmail.com> <alpine.BSF.2.00.1406070252270.21531@erdgeist.org> <CADWvR2gkeNaeVPizq_VubWhEHy3ywURJOdv9C=6PNybwYyFqRg@mail.gmail.com> <CAJ-Vmonm3aZr=kP293x90Am7VzWQQ65cTE8fiTZ6KAECegoZGQ@mail.gmail.com> <1402159374.20883.160.camel@revolution.hippie.lan> <CADWvR2guSYMKEm2HkzXNVuO%2BVS6=_a9jFBmKcSE2BzjYfiaUrQ@mail.gmail.com> <CAJ-Vmom=QOZtn1jQADPZfV10TXD4aoNQT7jhip_sp_=zQ04jog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 June 2014 20:15, Adrian Chadd <adrian@freebsd.org> wrote: > On 7 June 2014 14:38, Igor Mozolevsky <igor@hybrid-lab.co.uk> wrote: > > > > > > > > On 7 June 2014 17:42, Ian Lepore <ian@freebsd.org> wrote: > >> > >> On Sat, 2014-06-07 at 12:06 -0400, Adrian Chadd wrote: > >> > On 7 June 2014 10:19, Igor Mozolevsky <igor@hybrid-lab.co.uk> wrote: > >> > > On 7 June 2014 01:53, Dirk Engling <erdgeist@erdgeist.org> wrote: > >> > > > >> > >> > >> > >> On Sat, 7 Jun 2014, Daniel Janzon wrote: > >> > >> > >> > >> Is there any better way than doing the accept() call in one thread > >> > >> and > >> > >>> then > >> > >>> dispatch it to a thread on another core with any user space > method? > >> > >>> > >> > >> > >> > > See C10K problem [1]. > >> > > > >> > > > >> > > Why use accept() and not kevent()? You need to keep it portable? > >> > >> > >> > > > >> > > Has anyone rebutted the threads better than events paper[2] yet? > >> > > > >> > > > >> > > > >> > > 1. http://www.kegel.com/c10k.html > >> > > > >> > > 2. > >> > > > >> > > > https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf > >> > > >> > Not likely; but that paper talks about a threading model that isn't > >> > currently in use in popular UNIX operating systems. It also compares a > >> > lightweight thread implementation with a lightweight server to an > >> > event driven system with worker threads that acted pretty badly, > >> > causing extremely bad memory use and context switching. > >> > > >> > We've all gotten better at programming since then. > >> > >> Yeah, when I glanced at the link and saw it was a cite of a 2003 paper, > >> my gut reaction was "Yeah, it has been rebutted by 11 years of everyone > >> just getting on with their lives and evolving absolutely everything that > >> was tested into something completely different now." > > > > > > I can't possibly argue with that sort of scientific method, but back in > > 2008, someone did some stuff with Java and got interesting results[1]. > > > > > > 1. http://www.mailinator.com/tymaPaulMultithreaded.pdf > > > > It's Java, and its design also pulled in bits from the Java way you do IO. > > I think we can do better. I did say it was in Java, but so what? By 2008 Sun were going out of their way to make Java both scalable and zero-cost. The point I was making was that we set off with the assumption that kevent-based sockets are faster, therefore server (as a whole) was assumed to have a higher performance; and never bothered to actually measure it. On coding complexity front, from slide 36: The story of Rob Van Behren (as remembered by me from a lunch with Rob) Set out to write a high-performance asynchronous server system Found that when switching between clients, the code for saving and restoring values/state was difficult Took a step back and wrote a finely-tuned, organized system for saving and restoring state between clients When he was done, he sat back and realized he had written the foundation for a threading package -- Igor M.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADWvR2getzzd8we%2BYSQS6vq-7kJn2j-3WhQxWQAP9O8GNLWZOQ>