X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 826CDD78D2 for ; Sun, 20 Nov 2005 10:30:24 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 84004-09 for ; Sun, 20 Nov 2005 14:30:25 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr1.postgresql.org (Postfix) with ESMTP id C8329D70A1 for ; Sun, 20 Nov 2005 10:30:19 -0400 (AST) Received: from trofast.sesse.net ([129.241.93.32]) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1EdqCz-0002Bi-QQ for pgsql-performance@postgresql.org; Sun, 20 Nov 2005 15:30:23 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1EdqCF-0008Pe-00 for ; Sun, 20 Nov 2005 15:29:35 +0100 Date: Sun, 20 Nov 2005 15:29:35 +0100 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: Hardware/OS recommendations for large databases ( Message-ID: <20051120142935.GA32311@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <437FE2E4.5040600@rentec.com> <87y83jo0um.fsf@stark.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87y83jo0um.fsf@stark.xeocode.com> X-Operating-System: Linux 2.6.14 on a i686 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200511/412 X-Sequence-Number: 15669 On Sun, Nov 20, 2005 at 09:22:41AM -0500, Greg Stark wrote: > I don't think that's true. If the syscall was preemptable then it wouldn't > show up under "iowait", but rather "idle". The time spent in iowait is time in > uninterruptable sleeps where no other process can be scheduled. You are confusing userspace with kernel space. When a process is stuck in uninterruptable sleep, it means _that process_ can't be interrupted (say, by a signal). The kernel can preempt it without problems. /* Steinar */ -- Homepage: http://www.sesse.net/