From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 19:27:19 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 612D5CAA; Sat, 7 Jun 2014 19:27:19 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 ED7C72A41; Sat, 7 Jun 2014 19:27:18 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id f51so7013291qge.40 for ; Sat, 07 Jun 2014 12:27:18 -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=EsSacIYzxHm3kMZ4/JF1k9jFl7NErR+j9cIpEC6TFJM=; b=KFEiWhDB/xOX2e8tOmWfOFlvyvpYybjlmnyCuOIJGmcP0n4JXSKdHrN1SJ2Yup8v74 UgR2ty+wKHeMGGm1uqiU9L5C5fZovh132b4uttVBjXuwhstOwa6Bsf4jbwdZdklf6vCT /dkoQ2VdCp4cnUvZRm077/zim2DUJberYdqSc9TLupOGJszup5ykKyty5CX6NX8lTxeB VdAhOuZWJiTwTzMadk6jAf0QeaRNev54jb5DBqbuwZ6AaNLhtR/kDpT1SDi1Y10jUNo0 H3XZZS0d/s0dpYXUSg1YtmG5xBv0vMB2bU5dvFy8k8FWmcnNZc6YPlntpzk7tL43O5+E 1HnQ== X-Received: by 10.224.14.79 with SMTP id f15mr20279538qaa.96.1402169238068; Sat, 07 Jun 2014 12:27:18 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Sat, 7 Jun 2014 12:26:37 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> From: Igor Mozolevsky Date: Sat, 7 Jun 2014 20:26:37 +0100 X-Google-Sender-Auth: 1yJG7JDHc1uYE5CLmkO1TIbUjMo 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 19:27:19 -0000 On 7 June 2014 20:15, Adrian Chadd wrote: > On 7 June 2014 14:38, Igor Mozolevsky wrote: > > > > > > > > On 7 June 2014 17:42, Ian Lepore wrote: > >> > >> On Sat, 2014-06-07 at 12:06 -0400, Adrian Chadd wrote: > >> > On 7 June 2014 10:19, Igor Mozolevsky wrote: > >> > > On 7 June 2014 01:53, Dirk Engling 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.