From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:18:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CF21948; Sat, 7 Jun 2014 20:18:55 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9A142E32; Sat, 7 Jun 2014 20:18:54 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j5so6241388qaq.1 for ; Sat, 07 Jun 2014 13:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Q51wsdUdT7V0f3pU1bLYf2Dr1vRPtAzIWtXRjQs7bio=; b=0oDhkEHm2cURflhNfZg4zOB+RPZ0QvX2T8k2KdE4FvwhAITMbzum7KiXEcSGEThXh6 i2qIlimDQ95ZrUmOr/ljiV/jv9A6Q+ZCcBJu4eebLaxm8/ic8ixtkTYFbN6XibBUnL1k VpBoLZNGRAHEsZL7NKg7bQuPDabCmIx51RE68B6QF1y/RDL1p7kei/2/JfpKdgEKyZFT bKVkiRvIfXT2516q7uuSeRgX6YC8JFrdjiAvcs3Kt7vP0P6e90q+awJIyLjhlolewU3J SmmobtxagRbZPce7FOunZE7TgoFexl8iETzu9fUDEqkXYIOF8leoR5HA1FxDjP0inadz 5dWw== MIME-Version: 1.0 X-Received: by 10.140.91.5 with SMTP id y5mr19493940qgd.12.1402172333925; Sat, 07 Jun 2014 13:18:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 13:18:53 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 16:18:53 -0400 X-Google-Sender-Auth: h9TH_fUYcl4z7liU58z5S0NQZp8 Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:18:55 -0000 > 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. > The undeniable truth of the current state of CPU architecture is that while > the GHz remains the same (and in a lot of cases is actually going down), the > number of cores is on the increase, so it makes little sense to have a > server that doesn't take full advantage of all available resources. Agreed. > 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. > >> We can do better. > > > > > Quite likely- but the OP was asking what the current state is, and not what > could happen X years down the line. 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. 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. -a