From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUxIe-0002FM-Ts for qemu-devel@nongnu.org; Thu, 17 May 2012 05:47:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUxIY-0004qM-D0 for qemu-devel@nongnu.org; Thu, 17 May 2012 05:47:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUxIY-0004pz-58 for qemu-devel@nongnu.org; Thu, 17 May 2012 05:47:06 -0400 Message-ID: <4FB4C90D.1060605@redhat.com> Date: Thu, 17 May 2012 12:46:53 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1337169582-28312-1-git-send-email-owasserm@redhat.com> <1337169582-28312-9-git-send-email-owasserm@redhat.com> <4FB3D9A7.2060704@redhat.com> <4FB3DE10.6090506@redhat.com> <4FB3EABF.4020505@redhat.com> In-Reply-To: <4FB3EABF.4020505@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v10 8/9] Add set_cachesize command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, quintela@redhat.com, Petter Svard , stefanha@gmail.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com, Orit Wasserman , Benoit Hudzia , pbonzini@redhat.com, Aidan Shribman On 05/16/2012 08:58 PM, Eric Blake wrote: > On 05/16/2012 11:04 AM, Orit Wasserman wrote: > > >>> +- "value": cache size in bytes (json-int) > >> > >> Would it be any easier to take 'order' (log2 of the size) instead of the > >> actual cache size? That is, instead of calling "value":1048576, I would > >> rather type "value":20. > > Well the user is considering how much memory is going to be used and I though that it > > is simpler to use 1G than 30. > > Libvirt can cope with either style, so maybe it's worth waiting for > anyone else to chime in on which style is easier. Let's be consistent. It's best to use bytes everywhere (not kilobytes, not megabytes, not pages, not order, or anything else we can come up with). If you really want to specify order (not that I can think of a reason why), we can use a suffix: 20ORD == 1M == 1048576. btw, maybe it's better to handle a non-power-of-two cache size by rounding down. Less errors, less puzzlement, and less memory used. -- error compiling committee.c: too many arguments to function