From owner-freebsd-arch@FreeBSD.ORG Sun Mar 16 06:12:14 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405C9106564A for ; Sun, 16 Mar 2008 06:12:14 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 177D78FC37 for ; Sun, 16 Mar 2008 06:12:14 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m2G6CC13012954; Sun, 16 Mar 2008 02:12:13 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sat, 15 Mar 2008 20:12:46 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Kip Macy In-Reply-To: Message-ID: <20080315201153.X910@desktop> References: <20080315195328.V910@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: separating out memory checks from INVARIANTS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 06:12:14 -0000 On Sat, 15 Mar 2008, Kip Macy wrote: > On Sat, Mar 15, 2008 at 10:54 PM, Jeff Roberson > wrote: >> >> On Sat, 15 Mar 2008, Kip Macy wrote: >> >> > I find that the serialization of memory allocation frequently hides >> > race conditions. I would like to, at the very least, add an option to >> > disable the memory checks if not make the memory checks a completely >> > separate option. My knee jerk reaction to avoiding bikesheds is to >> > simply add it to my own tree and forget about it. However, this has >> > come up often enough that I feel that it warrants consideration. >> > >> > >> > Thoughts? >> >> One other option that I have frequently considered is to convert UMA from >> using an array of bytes to using bitfields to represent the free space in >> a slab. Then you could use atomics to update the required information. >> It'd be a bit of work. Maybe a good SoC? :) > > > Would it make it possible to do memory allocation without holding a > lock in the M_NOWAIT case? Yes, when I originally wrote the code it didn't require a lock because I relied on byte writes being atomic. However, we had platforms for which that wasn't true. (alpha). It may be that it's safe not to lock even now on x86/amd64. I don't know the specifics of the memory architectures on powerpc, arm, mips, etc. though. Jeff > > -Kip >