qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: ace <acelists@atlas.sk>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows.
Date: Sat, 03 Sep 2005 15:51:52 +0200	[thread overview]
Message-ID: <4319AA78.7070104@atlas.sk> (raw)
In-Reply-To: <20050830134218.17388.qmail@web50508.mail.yahoo.com>

Hi.

Two points for you:
1. currently your tempfile with qemu quest system memory is located on
disk. Is your disk working hard? If you have enough free ram that you
consider the ramdisk, the whole file is probably cached in host system
memory so that read/write access is fast. Of course there it will be
flushed to disk, but probably asynchronously and not every time anything
in the file changes (depends on windows filesystem settings). So it
probably doesn't slow qemu down too much. I think if you have the ram,
the ramdisk surelly will help, but I don't know by how much. I can test
that.

2. you say you can't see the temporary file. Neither do I, on linux. I
suspect it is not hidden using plain filesystem attributes. On linux, if
you open a file and then delete (unlink) it, you can still work with it
until you hold the file descriptor. Only when you close the file, it is
removed from disk. But as soon as you unlink it, all referrences to it
are removed from the filesystem hierarchy. Therefore, no other program
(e.g. dir, ls) except the filesystem kernel driver knows about it. You
see no file, but something is still using up disk space (if you use
programs to show free disk space). Maybe Windows supports this too.

Peter

Francois Rioux wrote:

> Filip,
>  
> I'm not trying to put the guest in ram.  As you state, let's Windows
> manage its whole memory, paging and swapping.  I agree it would be as
> dumb as setting up a ramdisk to put the swapfile. Let's not trying to
> outsmart the OS.
>  
> I was trying to follow Fabrice recommendation to set the QEMU temp
> directory to a RAM disk while using kqemu:
>  
> "When using KQEMU, QEMU will create a big hidden file containing the RAM
> of the virtual machine. For best performance, it is important that this
> file is kept in RAM and not on the hard disk. QEMU uses the `/dev/shm'
> directory to create this file because |tmpfs| is usually mounted on it
> (check with the shell command |df|). Otherwise `/tmp' is used as
> fallback. You can use the QEMU_TMPDIR shell variable to set a new
> directory for the QEMU RAM file. " (excerpt from his 'kqemu-doc.html' file).
> 
> I (maybe incorrectly) interpreted that as setting the temp dir in RAM. 
> But I'm not that familiar with Linux and I don't know what /shm or tmpfs
> are.  I guessed they were 'virtual' storage devices in RAM.  I'm simply
> trying to mimic that under Windows.  Had I been right, using a RAM disk
> to store the 'big hidden file containing the RAM of the virtual machine'
> would not be useless given enough ram is available, would it?  But I
> can't find that file at all under Windows and my understanding of the
> whole situation is probably wrong, or at least part of it.
>  
> Reading your other posts in this forum I understand you have an deep
> knowledge of Linux, Windows and QEMU insights so I take from your answer
> that RAMDISK is not gonna help kqemu.
>  
> Regards,
>  
> Francois
> 
> */Filip Navara <navaraf@reactos.com>/* wrote:
> 
>     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" /* 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
> 
> 
>     _______________________________________________
>     Qemu-devel mailing list
>     Qemu-devel@nongnu.org
>     http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> ------------------------------------------------------------------------
> Start your day with Yahoo! - make it your home page
> <http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

  parent reply	other threads:[~2005-09-03 14:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-29 16:56 [Qemu-devel] Re: qemu 0.7.1 + dkms-qvm86-0.7.1 (mandriva 2005 / cooker) produces version mismatch Hannes Fuchs
2005-08-29 18:05 ` [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows Francois Rioux
2005-08-29 18:53   ` John R. Hogerhuis
2005-08-29 21:59     ` Jim C. Brown
2005-08-30  7:29       ` [Qemu-devel] qemu optimization John R. Hogerhuis
2005-08-30 11:17         ` Paul Brook
2005-08-30 18:05           ` John R. Hogerhuis
2005-08-30 18:30             ` Paul Brook
2005-08-29 22:01   ` [Qemu-devel] QEMU_TMPDIR temp folder for KQEMU for Windows Jim C. Brown
2005-08-30  3:45     ` Francois Rioux
2005-08-30  9:08       ` Filip Navara
2005-08-30 13:42         ` Francois Rioux
2005-08-30 14:02           ` Paul Brook
2005-09-03 13:51           ` ace [this message]
2005-09-03 17:35             ` Doctor Bill
2005-09-03 14:48           ` Filip Navara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4319AA78.7070104@atlas.sk \
    --to=acelists@atlas.sk \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).