From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH RFC 5/5] KVM: This is the main part of the "moving dirty bitmaps to user space" Date: Tue, 13 Apr 2010 00:00:23 +0300 Message-ID: <4BC389E7.3040801@redhat.com> References: <20100409182732.857de4db.yoshikawa.takuya@oss.ntt.co.jp> <20100409183808.b72fc9a3.yoshikawa.takuya@oss.ntt.co.jp> <4BC2051B.9090101@redhat.com> <4BC28578.4050102@oss.ntt.co.jp> <4BC2E64E.1090202@redhat.com> <4BC388AE.9010903@oss.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Takuya Yoshikawa , mtosatti@redhat.com, kvm@vger.kernel.org To: Fernando Luis Vazquez Cao Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11656 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754093Ab0DLVA3 (ORCPT ); Mon, 12 Apr 2010 17:00:29 -0400 In-Reply-To: <4BC388AE.9010903@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 04/12/2010 11:55 PM, Fernando Luis Vazquez Cao wrote: >>> Sadly we don't have that for 32bit. We have to implement by ourselves. >>> >>> I tested two temporary implementations for 32bit: >>> 1. This version using copy_from_user() and copy_to_user() with >>> not nice vmalloc(). >>> 2. Loop with __get_user() and __put_user(). >>> >>> The result was 1 is much faster than 2. >> >> What about copy_from_user()/copy_to_user() through a 512 byte buffer >> on the kernel stack? > > > Reserving 512 bytes on the stack looks like too much, I'd rather > kmalloc a 512 byte buffer at VM > creation time and pass it down to the dirty page tracking code. Would > you be OK with such an > approach? But a generic copy_in_user() can't access that (I guess I wasn't clear - just like I want a generic set_bit_user(), I want a generic copy_in_user() instead of ifdefs in my code). But I guess we can make it as simple as possible using get_user()/put_user(), and someone will optimize it. Alternatively use a 256 byte buffer, should be fine for the stack and for performance. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.