From owner-freebsd-stable@FreeBSD.ORG Wed Mar 14 15:01:25 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F36C216A40E for ; Wed, 14 Mar 2007 15:01:24 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id DC8D313C48A for ; Wed, 14 Mar 2007 15:01:24 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2EEaSGQ078842; Wed, 14 Mar 2007 06:36:28 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2EEaSU6078841; Wed, 14 Mar 2007 07:36:28 -0700 (PDT) (envelope-from rizzo) Date: Wed, 14 Mar 2007 07:36:28 -0700 From: Luigi Rizzo To: Vlad GALU Message-ID: <20070314073628.A78775@xorpc.icir.org> References: <316F15B309F69F4CA5AB2C72BE26C21501ADFEFF@prowler.clarotech.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dudu@dudu.ro on Wed, Mar 14, 2007 at 03:48:38PM +0200 Cc: Emile Coetzee , freebsd-stable@freebsd.org Subject: Re: Openvpn tap uses 99% cpu time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 15:01:25 -0000 On Wed, Mar 14, 2007 at 03:48:38PM +0200, Vlad GALU wrote: > On 3/14/07, Emile Coetzee wrote: > > Since the latest updates to sys/net/if_tap.c (I suspect) in 6.2-STABLE > > my openvpn tap server is using up all available CPU time (99%) > > effectively killing the box. ... > It usually happens when OpenVPN is told to retry connecting to the > remote endpoint and the remote endpoint isn't accessible due to > network conditions. It happens the same even on Windows. something that often does the job is putting a usleep(1) right after the offending syscall (e.g. a select() returning with an error, or the like). This deschedules the current process for at least one tick, which is normally enough to change the busy-wait loop into one that still is busy-wait but only takes a tiny fraction of the cpu. Of course you want to usleep() only if there is a real error condition. cheers luigi