Alexander Graf wrote:
> Anthony Liguori wrote:
> > I'd prefer to stick to bug fixes for stable releases. Performance
> > improvements are a good motivation for people to upgrade to 0.13 :-)
>
> In general I agree, but this one looks like a really simple one.
Besides, there are too many reported
On Tue, May 18, 2010 at 9:43 PM, Stefan Hajnoczi wrote:
> I'll rerun with profiling tomorrow to see if calloc() makes a
> difference for general qemu_mallocz() usage.
The results are unchanged for direct calloc() instead of
malloc+memset. The memset() symbol is still at the top of the profile
be
On Tue, May 18, 2010 at 8:55 PM, Corentin Chary
wrote:
> I believe that if the allocation size is large enougth, getting a
> zeroed page can be almost free with clever memory management.
> Could you try to re-run your test with calloc and see what it does ?
> Speeding up all mallocz calls is proba
On Tue, May 18, 2010 at 9:02 PM, Stefan Hajnoczi wrote:
> On Tue, May 18, 2010 at 5:37 PM, Corentin Chary
> wrote:
>> Did you try to profile using calloc in qemu_mallocz instead of malloc +
>> memset ?
>
> No, I didn't try it. I don't see how it could perform on par with not
> clearing memory a
On Tue, May 18, 2010 at 5:37 PM, Corentin Chary
wrote:
> Did you try to profile using calloc in qemu_mallocz instead of malloc +
> memset ?
No, I didn't try it. I don't see how it could perform on par with not
clearing memory at all. Something is going to have to clear that
memory when using m
On Fri, May 14, 2010 at 11:52 PM, Stefan Hajnoczi
wrote:
> The VirtIOBlockRequest structure is about 40 KB in size. This patch
> avoids zeroing every request by only initializing fields that are read.
> The other fields are either written to or may not be used at all.
>
> Oprofile shows about 10%
Anthony Liguori wrote:
> On 05/18/2010 11:26 AM, Alexander Graf wrote:
>> Jes Sorensen wrote:
>>
>>> On 05/14/10 23:52, Stefan Hajnoczi wrote:
>>>
>>>
The VirtIOBlockRequest structure is about 40 KB in size. This patch
avoids zeroing every request by only initializing fields that
On 05/18/2010 11:26 AM, Alexander Graf wrote:
Jes Sorensen wrote:
On 05/14/10 23:52, Stefan Hajnoczi wrote:
The VirtIOBlockRequest structure is about 40 KB in size. This patch
avoids zeroing every request by only initializing fields that are read.
The other fields are either written
Jes Sorensen wrote:
> On 05/14/10 23:52, Stefan Hajnoczi wrote:
>
>> The VirtIOBlockRequest structure is about 40 KB in size. This patch
>> avoids zeroing every request by only initializing fields that are read.
>> The other fields are either written to or may not be used at all.
>>
>> Oprofile
On 05/14/10 23:52, Stefan Hajnoczi wrote:
> The VirtIOBlockRequest structure is about 40 KB in size. This patch
> avoids zeroing every request by only initializing fields that are read.
> The other fields are either written to or may not be used at all.
>
> Oprofile shows about 10% of CPU samples
Am 14.05.2010 23:52, schrieb Stefan Hajnoczi:
> The VirtIOBlockRequest structure is about 40 KB in size. This patch
> avoids zeroing every request by only initializing fields that are read.
> The other fields are either written to or may not be used at all.
>
> Oprofile shows about 10% of CPU sam
On Sun, May 16, 2010 at 2:25 PM, Christoph Hellwig wrote:
> On Fri, May 14, 2010 at 10:52:30PM +0100, Stefan Hajnoczi wrote:
>> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
>> index b05d15e..d270225 100644
>> --- a/hw/virtio-blk.c
>> +++ b/hw/virtio-blk.c
>> @@ -105,8 +105,10 @@ static void virt
On Fri, May 14, 2010 at 10:52:30PM +0100, Stefan Hajnoczi wrote:
> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
> index b05d15e..d270225 100644
> --- a/hw/virtio-blk.c
> +++ b/hw/virtio-blk.c
> @@ -105,8 +105,10 @@ static void virtio_blk_flush_complete(void *opaque, int
> ret)
>
> static Virt
13 matches
Mail list logo
