From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1EA2QK-00048u-R2
	for qemu-devel@nongnu.org; Tue, 30 Aug 2005 05:28:57 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1EA2QD-00045y-T4
	for qemu-devel@nongnu.org; Tue, 30 Aug 2005 05:28:53 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1EA2QD-0003nZ-Ad
	for qemu-devel@nongnu.org; Tue, 30 Aug 2005 05:28:49 -0400
Received: from [195.250.128.75] (helo=smtp2.vol.cz)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1EA29G-00068D-Gl
	for qemu-devel@nongnu.org; Tue, 30 Aug 2005 05:11:18 -0400
Received: from [10.0.0.2] (prg-v-6-220.static.adsl.vol.cz [62.177.70.220])
	by smtp2.vol.cz (Postfix) with ESMTP id 03D6B60FA9
	for <qemu-devel@nongnu.org>; Tue, 30 Aug 2005 11:08:50 +0200 (CEST)
Message-ID: <43142222.7000904@reactos.com>
Date: Tue, 30 Aug 2005 11:08:50 +0200
From: Filip Navara <navaraf@reactos.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.
References: <20050830034543.54955.qmail@web50503.mail.yahoo.com>
In-Reply-To: <20050830034543.54955.qmail@web50503.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Francois Rioux wrote:
[snip]

> Ramdisk might have been a real performance accelerator for Windows 
> hosts with enough RAM available.  Since I can't find the temp memory 
> image file is saved, I can't use that option.

Why do you think that it would improve performance? Sorry, but that's 
complete rubbish... The guest RAM is allocated using standard virtual 
memory functions and as long as you have enough memory the system will 
probably leave it in the physical RAM anyway... If you don't, it's 
swapped out to page file. This is much more versatile solution since you 
don't have to reserve a chunk of the RAM for a disk and _permanently_ 
waste your memory resources this way...

>  
>
> */"Jim C. Brown" <jma5@umd.edu>/* wrote:

[snip]

>     IIUC this is a reference to shmfs. So this doesn't apply to KQEMU
>     on Windows
>     hosts. I'm not an expert on the Windows versions tho, so I'm not
>     100% sure of
>     this.
>
Correct.

- Filip