Re: Best practice for accepting TCP connections on multicore?

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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"