From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 26 18:19:38 2011 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 EAA58106564A for ; Tue, 26 Jul 2011 18:19:38 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8A2E8FC17 for ; Tue, 26 Jul 2011 18:19:38 +0000 (UTC) Received: by gwb15 with SMTP id 15so589572gwb.13 for ; Tue, 26 Jul 2011 11:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xT7N7xgqMLV8eKsqk7oFXy4K4rMg+jhflwfpDkm/PdI=; b=mP98+0a1M7Qsz9W9SMcebAvONwkfcn/uHMP6Uvuo4LrPYdQ6KBcFJDHdL3QU04N1BL jJampUf7JThT6FIquuA6OwPp/nooIvixY+Zikx2ZS0d4udIJiWzQvDajPoWRJIpxppzU fWLxeOVD5PHD1FKXTzW5bNb+BxLPz0C8Ob2fc= MIME-Version: 1.0 Received: by 10.142.140.13 with SMTP id n13mr1872604wfd.289.1311704377508; Tue, 26 Jul 2011 11:19:37 -0700 (PDT) Received: by 10.142.199.13 with HTTP; Tue, 26 Jul 2011 11:19:37 -0700 (PDT) In-Reply-To: References: <4E2D2FE7.4070907@rice.edu> <4E2DC07F.9070701@rice.edu> <4E2DCF02.4060009@rice.edu> Date: Tue, 26 Jul 2011 20:19:37 +0200 Message-ID: From: Davide Italiano To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: UMA large allocations issues 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, 26 Jul 2011 18:19:39 -0000 It seems that today I've some good news. I've done some job. Before I tried stuffs userspace http://davit.altervista.org/malloc_new.c , then I improved my patch a bit http://davit.altervista.org/uma_large_allocations.patch ) So, the situation is follow. System starts (before it doesn't), but I've a fatal trap 9, hmm, that's not great, and I guess that's not fault of mine, it's caused from buf_hash_find() in arc.c I've taken a look at arc.c code but doesn't seems that that function performs large allocations. What I've done is taking two shots (one about the panic the other one about the bt http://dl.dropbox.com/u/3530969/zfs_fail.png http://dl.dropbox.com/u/3530969/zfs_fail2.png ) I thought in a first phase that the trouble was related to the fact that there weren't enough chunks, so I increased CHUNKS_SIZE variable (now it's set to 200), but the issue remains the same. Ideas? Cheers Davide