Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Jun 2014 21:37:40 +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:  <CADWvR2iqKFOUFz66ULrP2xk3JOjm=dbzT7YtKMbhEqyEc9WLpw@mail.gmail.com>
In-Reply-To: <CAJ-Vmok-2eCRuLKwrVCWbo2q-SzEMxma3jrvPFajBkqhUA2Q1Q@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> <CADWvR2getzzd8we%2BYSQS6vq-7kJn2j-3WhQxWQAP9O8GNLWZOQ@mail.gmail.com> <CAJ-Vmo=qo5gGmD6PAeoGLTRpS=wk0=Bm%2Bc49NHLM2BBhVHuphQ@mail.gmail.com> <CADWvR2iyXQ6SkA4Dhy_A3QxsN5sutbC2wS3UpkptBz48Fp8=ZA@mail.gmail.com> <CAJ-Vmok-2eCRuLKwrVCWbo2q-SzEMxma3jrvPFajBkqhUA2Q1Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7 June 2014 21:18, Adrian Chadd <adrian@freebsd.org> wrote:

> > Not quite - the gist (and the point) of that slide with Rob's story was
> that
> > by the time Rob wrote something that could comprehensively deal with
> states
> > in an even-driven server, he ended up essentially re-inventing the wheel.
>
> I read the same slides you did. He didn't reinvent the wheel - threads
> are a different concept - at any point the state can change and you
> switch to a new thread. Event driven, asynchronous programming isn't
> quite like that.
>

Not quite- unless you're dealing with stateless HTTP, you still need to
know what the "current" state of the "current" connection is, which is the
point of that slide.


> Paul Tyma's presentation posted earlier did conclude with various models
> for
> > different types of daemons, which the OP might find at least interesting.
>
> Agreed, but again - it's all java, it's all linux, and it's 2008.


Agreed, but threading models are platform-agnostic.


The current state is that threads and thread context switching are
> more expensive than you'd like. You really want to (a) avoid locking
> at all, (b) keep the CPU hot with cached data, and (c) keep it from
> changing contexts.
>

Agreed, but uncontested locking should be virtually cost-free (or close to
that), modern CPUs have plenty of L2/L3 cache to keep enough data nearby,
and there are plenty of cores to keep cycling in the same thread-loop, and
hyper-threading helps with ctx switching (or at least is supposed to). In
any event, shuttling data between RAM and cache (especially with the on-die
RAM controllers, and even if data has to go through QPI/HyperT), and the
cost of changing contexts is tiny compared to that of disk and network IO.


It's cool man, I'm actually hacking on this shit to push things
> forward. For fun. Because hey, if noone is going to pay me to do it
> for real, I may as well get some pleasure out of it.


All I can do is to thank you for that, and I hope others join me in doing
so!


-- 
Igor M.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADWvR2iqKFOUFz66ULrP2xk3JOjm=dbzT7YtKMbhEqyEc9WLpw>