From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964970AbVHYNNv (ORCPT ); Thu, 25 Aug 2005 09:13:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964974AbVHYNNv (ORCPT ); Thu, 25 Aug 2005 09:13:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:18368 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S964970AbVHYNNt (ORCPT ); Thu, 25 Aug 2005 09:13:49 -0400 To: Ray Fucillo Cc: linux-kernel@vger.kernel.org Subject: Re: process creation time increases linearly with shmem References: <430CBFD1.7020101@intersystems.com> <430D0D6B.100@yahoo.com.au> <430DC285.7070104@intersystems.com> From: Andi Kleen Date: 25 Aug 2005 15:13:45 +0200 In-Reply-To: <430DC285.7070104@intersystems.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Ray Fucillo writes: > > The application is a database system called Caché. We allocate a > large shared memory segment for database cache, which in a large > production environment may realistically be 1+GB on 32-bit platforms > and much larger on 64-bit. At these sizes fork() is taking hundreds > of miliseconds, which can become a noticeable bottleneck for us. This > performance characteristic seems to be unique to Linux vs other Unix > implementations. You could set up hugetlbfs and use large pages for the SHM (with SHM_HUGETLB); then the overhead of walking the pages of it at fork would be much lower. -Andi