Date: Sat, 15 Mar 2008 20:12:46 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: Kip Macy <kip.macy@gmail.com> Cc: arch@freebsd.org Subject: Re: separating out memory checks from INVARIANTS Message-ID: <20080315201153.X910@desktop> In-Reply-To: <b1fa29170803152255g402d08abo1b0711176f55d763@mail.gmail.com> References: <b1fa29170803152244k5f31065dt135b605a54a4d0da@mail.gmail.com> <20080315195328.V910@desktop> <b1fa29170803152255g402d08abo1b0711176f55d763@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Mar 2008, Kip Macy wrote: > On Sat, Mar 15, 2008 at 10:54 PM, Jeff Roberson > <jroberson@chesapeake.net> 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080315201153.X910>