From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 19:15:20 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 1AECCB31; Sat, 7 Jun 2014 19:15:20 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (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 BB3402969; Sat, 7 Jun 2014 19:15:19 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so6188389qaq.27 for ; Sat, 07 Jun 2014 12:15:19 -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=qku3yGfHaJJyXMbq3ZFVe2UTzCre9xhcFDyeTndrpFs=; b=jK/2QVHnMZYUaBCeDN5L2Lmx0HguT25vv1jD2Gp/UA688M06zbiu19Y97hoWi+BUmy /jEFLYsmcN/+WLOTpqK9oeJerDTYSLVIPe4SqWhzmn9ABn82Qu1i3akxDn+L5lloWL5i /OcZLNJ3bTvkRXwwOGKjlpuI6c0xPF4hsoelGlP1ieY2RbaG7Ng93XgWRDkdIBHrGgG6 V4cdWu4HtbhHSJUDHv+M6DUww3QGVnHK6RFhzKFXNwR4drApYpeVMl3tGvG5ZjNVOqwZ d6cgwZpaC0SHHA5MTEZEalwW9wCERLUGTlgPQFZMJk/FJUvcVmtEV2Dfk6+ySUJdu+ra rcPg== MIME-Version: 1.0 X-Received: by 10.224.135.66 with SMTP id m2mr20561977qat.55.1402168518856; Sat, 07 Jun 2014 12:15:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 12:15:18 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 15:15:18 -0400 X-Google-Sender-Auth: aHAR2FY7IXwlzEkqEbZrF7akBm0 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 19:15:20 -0000 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. -a