Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S265596AbSJXSdt>; Thu, 24 Oct 2002 14:33:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S265597AbSJXSdt>; Thu, 24 Oct 2002 14:33:49 -0400
Received: from [195.223.140.120] ([195.223.140.120]:17976 "EHLO
	penguin.e-mind.com") by vger.kernel.org with ESMTP
	id <S265596AbSJXSdq>; Thu, 24 Oct 2002 14:33:46 -0400
Date: Thu, 24 Oct 2002 20:40:05 +0200
From: Andrea Arcangeli <andrea@suse.de>
To: chrisl@vmware.com
Cc: Andrew Morton <akpm@digeo.com>, linux-kernel@vger.kernel.org,
       chrisl@gnuchina.org
Subject: Re: writepage return value check in vmscan.c
Message-ID: <20021024184005.GT3354@dualathlon.random>
References: <20021024082505.GB1471@vmware.com> <3DB7B11B.9E552CFF@digeo.com> <20021024113106.GE3354@dualathlon.random> <20021024183024.GC1398@vmware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021024183024.GC1398@vmware.com>
User-Agent: Mutt/1.3.27i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2415
Lines: 42

On Thu, Oct 24, 2002 at 11:30:24AM -0700, chrisl@vmware.com wrote:
> On Thu, Oct 24, 2002 at 01:31:06PM +0200, Andrea Arcangeli wrote:
> > On Thu, Oct 24, 2002 at 01:36:43AM -0700, Andrew Morton wrote:
> > 
> > you need to preallocate the file, then to mmap it. If you do, the kernel
> > won't throw the data away. So the fix for vmware is to preallocate the
> > file and later to mmap it. This way you will be notified by -ENOSPC if
> > you run out of disk/shmfs space.  Other than this I'm not so against the
> > MAP_SHARED like Andrew, the reason the API is not so clean is that we
> > cannot have an API at all inside a page fault to notify userspace that
> > the ram modifications cannot be written to disk. the page fault must be
> > transparent, there's no retvalue, so if you run out of disk space during
> > the page fault, the page fault cannot easily tell userspace. As said the
> > fix is very easy and consists in preallocating the space on disk (I
> > understand that on shmfs it may not be extremely desiderable since you
> > may prefer to defer allocation lazily to when you will need the memory
> > but assuming your allocations are worthwhile it won't make difference
> > after a few minutes/hours of usage and this way you will trap the -ENOSPC).
> 
> But preallocate the vmware ram file on disk is too expensive. It will slow
> down the guest OS boot up a lot. Many user measure how fast vmware is by
> counting how many seconds it takes to boot a windows guest for example.
> For those virtual machine which have 2G or ram, how long does it take
> to write a file with 2G of data?

unfortunately I see no way around it and patching the kernel to loop
forever on dirty pages that may never be possible to write doesn't look
safe. You could check the free space on the fs and bug the user if it
has less than 2G free (still it's not 100% reliable, it's a racy check,
but you could also add a 100% reliable option that slowdown the startup
of the vm but that guarantees no corruption can happen).

Furthmore if your machine has 2G of data you're likely to have >2G of
ram and shmfs should be quick allocating 2G in such case, maybe 2/3
seconds?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/