From owner-freebsd-arch  Tue Oct  8 13:51:46 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 9B12937B401
	for <arch@FreeBSD.ORG>; Tue,  8 Oct 2002 13:51:45 -0700 (PDT)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3B3DD43E4A
	for <arch@FreeBSD.ORG>; Tue,  8 Oct 2002 13:51:45 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g98KpjPQ084794;
	Tue, 8 Oct 2002 13:51:45 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.12.5/8.12.4/Submit) id g98KpjU1084793;
	Tue, 8 Oct 2002 13:51:45 -0700 (PDT)
	(envelope-from dillon)
Date: Tue, 8 Oct 2002 13:51:45 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200210082051.g98KpjU1084793@apollo.backplane.com>
To: "Vladimir B. " Grebenschikov <vova@sw.ru>
Cc: Nate Lawson <nate@root.org>, arch@FreeBSD.ORG
Subject: Re: Database indexes and ram (was Re: using mem above 4Gb was:
	swapon some regular file)
References: <Pine.BSF.4.21.0210081209010.11243-100000@root.org>
	<1034105993.913.1.camel@vbook.express.ru> 
	<200210082015.g98KFFrq084625@apollo.backplane.com> <1034109053.913.7.camel@vbook.express.ru>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG


:Mattew, please look at my initial posting. My idea is to extend ram
:available for storing such thing as index above 4Gb (actually about 3Gb)
:limit, if there more physical ram. Current mmap(read vm) implementation
:will map/cache only in memory below 4Gb not depending of amount of
:physical ram.

    Well, this has been discussed before.  The issue with accessing ram
    over 4GB, apart from the fact that the page tables double in size (you
    have to use 64 bit pte's instead of 32 bit pte's) is that DMAing to/from
    memory above 4GB can be rather tricky.  This creates all sorts of
    problem including not necessarily being able to read() or write()
    above the 4G mark (in regards to physical ram) without a lot of mess
    in the OS .. bounce buffers redux, so to speak. 

    So while it would be possible use such memory as unswappable, unIOable
    anonymous-only memory, such use would be fairly limited and might not
    be worth implementing for a 32 bit platform.  At that point you might
    as well move to a 64 bit platform.

    It also might be more effective to spend that money on more ram for
    the RAID system backing the database rather then trying to bump the
    PC past the 4G mark, or spend that money on purchasing a second
    server and distributing the load across the two servers.  The types
    of accesses to the index that might result in cacheable table data are
    also the types of accesses to the index that will likely result in
    cacheable index data.  Using the same argument, the types of accesses
    that might result in an uncacheable index would also likely result in
    uncacheable table data which means you are going to run up against 
    seek/read problems on the table data, making it more worthwhile to
    spend the money on beefing up the storage subsystem.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message