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>