From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 16:41:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A50106566C; Mon, 11 Jul 2011 16:41:53 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78FDD8FC0C; Mon, 11 Jul 2011 16:41:53 +0000 (UTC) Received: by yxl31 with SMTP id 31so438081yxl.13 for ; Mon, 11 Jul 2011 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=872VSh5mEbtlGnJwpV2XYju6aNwmDVR/TEI+hs2UfFM=; b=GnrKtlDUyXCzn+H5eMqOIwAYe8PfQshe5lLVdt7kjvFFqGUJoN/LmBv1Kv4a7459H7 hgx/KbT/47AA6zJJXIKUjT7WVoYCP9UicsTdxSbee8DLXFhh/J3EuwNLCFzlsPynYB8e fayYjMkEPl1sjV/l/SlWjmQHgob7Hu+CkbXu8= Received: by 10.101.108.3 with SMTP id k3mr1151098anm.129.1310400892089; Mon, 11 Jul 2011 09:14:52 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.252.8 with HTTP; Mon, 11 Jul 2011 09:14:12 -0700 (PDT) In-Reply-To: <4E1B1198.6090308@FreeBSD.org> References: <20110706170132.GA68775@troutmask.apl.washington.edu> <5080.1309971941@critter.freebsd.dk> <20110706180001.GA69157@troutmask.apl.washington.edu> <4E14A54A.4050106@freebsd.org> <4E155FF9.5090905@FreeBSD.org> <20110707151440.GA75537@troutmask.apl.washington.edu> <4E160C2F.8020001@FreeBSD.org> <20110707200845.GA77049@troutmask.apl.washington.edu> <4E1B1198.6090308@FreeBSD.org> From: Ivan Voras Date: Mon, 11 Jul 2011 18:14:12 +0200 X-Google-Sender-Auth: S9C1lVRwPNEnk-aT5SQl9nnMWGU Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:41:53 -0000 On 11 July 2011 17:07, Andriy Gapon wrote: > Yeah, but what problem is demonstrated here? > Are we confident that non-even workload is inherently bad? > E.g.: > 79.39 + .. + 77.59 < 5 * 80 =3D 400 > 100.00 + ... + 55.18 ~~ 402 which is more than theoretically possible :-) > So it would _appear_ that with ULE we get more work out of available CPUs= . It depends... I am not really concerned about the percentages; for many things, including "green computing" and TurboBoost it is beneficial to have one loaded CPU core and the rest of them idling (so they can be slowed down, or the loaded ones "boosted" - if we even support this). >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMM= AND >> 1318 kargl 1 103 0 370M 294M CPU0 0 1:31 100.00% sas= mp >> 1319 kargl 1 103 0 370M 294M RUN 1 1:29 100.00% sas= mp >> 1322 kargl 1 99 0 370M 294M CPU2 2 1:03 87.26% sasm= p >> 1320 kargl 1 91 0 370M 294M RUN 3 1:07 60.79% sasm= p >> 1321 kargl 1 89 0 370M 294M CPU3 3 1:06 55.18% sasm= p What I'd like to know is how do the priority calculations come into this - as the OP's problem sort of reminds of livelocking. > P.S. Not saying that this is the case here, but I've seen the following s= cenario > in real life. =C2=A0People add only nominal support for some platform in = their software > - when they don't know how to properly implement some feature, they just = drop that > feature or implement it very suboptimally. =C2=A0Then other people use ba= d performance > of that software on that platform as indication that there is something w= rong with > the platform, not the software. Yes but as a minority platform, it eventually becomes "our" problem...