From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 18:05:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E86E41065673 for ; Tue, 14 Feb 2012 18:05:41 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 579218FC1B for ; Tue, 14 Feb 2012 18:05:41 +0000 (UTC) Received: by werm13 with SMTP id m13so212256wer.13 for ; Tue, 14 Feb 2012 10:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1+zTMppW5652MrssHsEEShwGeR3ZQhM015Asiw/RqgI=; b=TB/yPUeDD61Tf1xlGIjhsaZ18m5z423sTCJjFjESqDxQBr3RkCdrUFE0/R3Ydjo1bk Dp9dPg3mAaGBZFZ7h7N6lPyGxl58RhZNfcMLni/UGeG9UQLM9XymhUfT+rP+hElcIef7 JSb3AUTjKc6VgImF5XmgL38ETnaTADAkFiwPI= Received: by 10.216.131.78 with SMTP id l56mr1582352wei.56.1329242740194; Tue, 14 Feb 2012 10:05:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.15.90 with HTTP; Tue, 14 Feb 2012 10:05:10 -0800 (PST) In-Reply-To: <20120214170533.GA35819@DataIX.net> References: <4F3A9266.9050905@freebsd.org> <20120214170533.GA35819@DataIX.net> From: Eitan Adler Date: Tue, 14 Feb 2012 13:05:10 -0500 Message-ID: To: Jason Hellenthal Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmyHpy2PDE6ujWBGWIyhZNfDWrB6OBEC4EYCQHcQ50BfIMnEEuVTvyHdDGDBdggel7kGUws Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:05:42 -0000 On Tue, Feb 14, 2012 at 12:05 PM, Jason Hellenthal wrote: > How about core redundancy ? effectively this would reduce the amount of > available cores in half in you spread a process to run on two cores at > the same time but with an option to adjust this per process etc... I > don't see it as unfeasable. There are a number of papers discussing core redundancy. They pretty much all work the same way: process the work on two different cores (or verify some subset of the work on the second core), and wait for both cores to return prior to the commit phase. One example: www.eecs.umich.edu/~taustin/papers/MICRO32-diva.pdf Another example: www.ee.duke.edu/~sorin/papers/ieeemicro08_argus.pdf These don't use existing cores on a multi-core chip, but instead use a "functional correctness" chip but I've seen designs that use the former as well. -- Eitan Adler