From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:38:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C562E44; Sat, 7 Jun 2014 20:38:22 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (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 C59FD2FB9; Sat, 7 Jun 2014 20:38:21 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id hw13so6148380qab.18 for ; Sat, 07 Jun 2014 13:38:21 -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:from:date:message-id :subject:to:cc:content-type; bh=lQum4Vm/qYIKhvKZDU6ldcIqEnXGUngo0FBsgnc5UB4=; b=zVVy9+i+7EIdAa4SIOhD136r15I/U6s+LUjSq4mrVL9S79anDKgBMSXfLyXdqxvtF9 8ckmoh43f+uLMZtSDtYpCc18ApBcROnVJ3QI3sQ1IF3MY84De7Ni067OV/TTu6FZ4QcE UM4TYVQhS7eZiNA0qepWeJXUcS+L545ApQsAV2LR0QgZe4/cO5kq4+Si1vNJVjQTv2DP WJDBazr9mXP+BvTMBq+Y+X3m3N+6gfs9ItU/JN9uXz0ugrGe7i7Wd6reoHzQOjmzKVjk m9V4UySKD5VSW0Ek94jsB1dnLaokzg1HLqImMGzgVh9lm5CW3IcQvmEwmDMvU/g5v08h ycaQ== X-Received: by 10.140.49.171 with SMTP id q40mr19716821qga.7.1402173500869; Sat, 07 Jun 2014 13:38:20 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Sat, 7 Jun 2014 13:37:40 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> From: Igor Mozolevsky Date: Sat, 7 Jun 2014 21:37:40 +0100 X-Google-Sender-Auth: r_N6XmYfv66zcxB2VZ18zchzNUg Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 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:38:22 -0000 On 7 June 2014 21:18, Adrian Chadd 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.