From owner-freebsd-stable@FreeBSD.ORG Fri Mar 23 18:39:45 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 654D916A402 for ; Fri, 23 Mar 2007 18:39:45 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 1633113C4E9 for ; Fri, 23 Mar 2007 18:39:44 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1354186ana for ; Fri, 23 Mar 2007 11:39:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=LIH3Yp6mwatqz8ycUQ3DhInukxczkpRmLNqZZPiN8lo4BUaSbZ0IZ6i1hysxu8IpbpV/cAD+emJZWUWD0R+mgUwO+FLq0NFOof8Qx/O4Hy4MGDD59vVZt5v5TdneNYpKYfIkSgDgooIm8nA1lEdwGF3s6ySTnj6/lrN2HopbHEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ltIxkxOI0J5SvtE1uh8Xp5mQlc2mDAQrfg5VUjAW0RN3OGJgagtY+h8OT6/n5YfL8zflyrXJXeXlYrueuK7ccOWgk9L4l8783tgydXzE/g+XtlYe33a0iUkKgFExjc3bu5dATPOT4cOCv7tfiU8pwB6qwYm0LLizRdl+pA5gx9U= Received: by 10.100.197.15 with SMTP id u15mr2890766anf.1174675183648; Fri, 23 Mar 2007 11:39:43 -0700 (PDT) Received: by 10.100.174.20 with HTTP; Fri, 23 Mar 2007 11:39:43 -0700 (PDT) Message-ID: <1dbad3150703231139t62a24bc1w616080b97f6b573c@mail.gmail.com> Date: Fri, 23 Mar 2007 19:39:43 +0100 From: "Michael Schuh" To: freebsd-stable@freebsd.org, michael.schuh@gmail.com In-Reply-To: <200703231626.l2NGQukl004840@lurza.secnetix.de> MIME-Version: 1.0 References: <1dbad3150703221655w62284ed7o8a5c7440aca45891@mail.gmail.com> <200703231626.l2NGQukl004840@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: another error with md malloc based fs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2007 18:39:45 -0000 Hi Oliver, Hi @list, yes that's exatly what i have in my mind, after the explainings from Chuck. thanks very much cheers michael 2007/3/23, Oliver Fromme : > > Michael Schuh wrote: > > Chuck Swiger wrote: > > > Michael Schuh wrote: > > > > i can't understand how malloc can eat all available > > > > memory, i have 2Gigs of it ;-) > > > > so it seems to me i know what i doing, if > > > > i have 1,6 Gigs free Memory, and i say ok get me 750Megs from > > > > my 1,6 Gigs of free Memory, what was faulty on that???? > > > > > > The two choices involve a swap-based RAMdisk, which can use all of > > > the available physical RAM it needs to, since this memory is > > > swappable, or a kernel-memory-based RAMdisk, which uses wired-down > > > memory from within the kernel. > > > > Ok, so that is it harder to understand for me in the first time, > > if i understand it now right the swap or file based memory backend > > is also in the ram, but it get another way managed from kernels vm. > > the malloc based ramdisk get's not reallly managed by the kvm, > > but it underlays under the paging and swapping, and also > > ba the "thread-killer" there shot's thread down it it get's to much > > work for the system.... > > > > i hope i understand this right, it is important for me... > > Let me try to explain it with a little different words. > The following is a bit simplified, but it should give > you an idea about the advantages and disadvantages of > each md disk type. > > First of all, _both_ "malloc" and "swap"-backed md disks > are RAM disks. You don't have to worry that a swap-backed > md disk will be created on your swap partiton. It's not. > It will reside in RAM, just like a "malloc" md disk. > > However, the difference is that a malloc md disk uses > memory from the KVM area (kernel virtual memory), which > is hardwired into the RAM. It cannot be paged, and it > is taken from the kernel's own memory pool, which is > usually much smaller than your total available RAM. > It's taken from the same pool of RAM that's used for > network buffers, driver data and similar things. > > On the other hand, "swap-backed" md disks use regular > memory, so to speak, just like a normal user process. > That also means that they are pageable, which means > that they can be paged to swap if necessary (if the > systems runs low on RAM). That's what "swap-backed" > means. Because of that, they don't have a size limit > (well, they shouldn't be bigger than your RAM + swap, > of course). If there is enough RAM, then they will > stay completely in RAM and will _not_ touch your swap > at all. > > For typical RAM disks, such as for /tmp, you should use > a swap-backed md disk (it should be the default). The > "malloc" type should be used only for rather small, > special uses. > > I hope it's now a little clearer. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehrun= g: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC= n- > chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb= hart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "[...] one observation we can make here is that Python makes > an excellent pseudocoding language, with the wonderful attribute > that it can actually be executed." -- Bruce Eckel > --=20 =3D=3D=3D michael-schuh.net =3D=3D=3D Michael Schuh Preu=DFenstr. 13 66111 Saarbr=FCcken phone: 0681/8319664 mobil: 0177/9738644 @: michael.schuh@gmail.com =3D=3D=3D Ust-ID: DE251072318 =3D=3D=3D