Date: Thu, 22 Dec 2005 16:22:51 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: James Long <list@museum.rain.com> Cc: Brooks Davis <brooks@one-eyed-alien.net>, freebsd-questions@freebsd.org Subject: Re: Reboots under 6.0 while exercising md device Message-ID: <20051223002251.GA24821@odin.ac.hmc.edu> In-Reply-To: <20051223001102.GA32544@ns.museum.rain.com> References: <20051222035049.GA25222@ns.museum.rain.com> <20051222043519.GA4610@odin.ac.hmc.edu> <20051223001102.GA32544@ns.museum.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 22, 2005 at 04:11:02PM -0800, James Long wrote: > On Wed, Dec 21, 2005 at 08:35:19PM -0800, Brooks Davis wrote: > > On Wed, Dec 21, 2005 at 07:50:49PM -0800, James Long wrote: > [snip] > > >=20 > > > What do I need to fix to be able to use a RAM-backed filesystem? > >=20 > > From mdconfig(8): > >=20 > > -t type > > Select the type of the memory disk. > >=20 > > malloc Storage for this type of memory disk is allocated= with > > malloc(9). This limits the size to the malloc bu= cket > > limit in the kernel. If the -o reserve option is= not > > set, creating and filling a large malloc-backed m= emory > > disk is a very easy way to panic a system. > >=20 > > As a rule, swap or vnode backed md devices are a better idea than malloc > > ones. > >=20 > > -- Brooks >=20 > Thank you very much. That not only works much better, it shatters my=20 > ignorant misconception about the -t switch. >=20 > If I may: >=20 > I naively assumed that a malloc'ed RAMDISK would just remove X number > of bytes of physical RAM from FreeBSD's VM system, and dedicate that > RAM to a memory disk. Since this RAM would now be outside the VM > system, contents of such RAM could never be swapped out, thus my > memory disk would always be fast, but would reduce the physical RAM > available to the VM system. It allocates kernel address space which is quite scarce on 32-bit platforms. I'm not sure if it allocated physical memory. Given the panicking behavior, I suspect that is deferred. > I assumed a swap-backed disk would do similar, but would be subject to > swapping if the memory disk data hadn't been accessed recently, and > demand for new VM pages became sufficient to force the memory disk > out of physical RAM into swap. My memory disk would usually be fast, > provided that I accessed it frequently. Parts of the disk that were > not accessed frequently could be swapped out to free up physical RAM, > and re-accessing those parts would then mean a disk access to swap in > the pertinent pages. I believe this is mostly accurate. If you're actually out of memory, there's a good chance you're going to be swapping anyway so this might or might not actually cost you anything. If you have frequent, randomly distributed access to the file system it's likely to be expensive. On the other hand, if there are hot spots, the swapping may be beneficial because it will allow other processes to proceed more efficiently. > I assumed a file-backed disk would be about the same as a swap-backed > md, except that it's paged to and from a file system, instead of a > swap partition. Basically. > How much of that is wrong? :) > > And would *any* program that tried to malloc 500 megs of RAM be likely > to crash the system, or is this a unique skill that mdconfig has > mastered? No, just any kernel process. Userland processes have around 2GB (IIRC, 2.5GB by default) of address space each and the kernel gets what's left. Since the kernel has to service everything else, that space goes fast. 64-bit architectures aren't so badly off since they have 2^63 bytes of address space for the kernel. They are still constrained by physical memory so a large malloc late in the game may fail. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDq0NaXY6L6fI4GtQRAmwXAJwKq6Dgwx8+SxRULyFcks7KPXvhTgCgkoC4 rEh3EixjdJuO0G1i0jwSuj0= =2+5j -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051223002251.GA24821>