> Am 27.06.2016 um 14:39 schrieb Stefan Hajnoczi :
>
>> On Fri, Jun 24, 2016 at 12:45:49PM +0200, Peter Lieven wrote:
>>> Am 24.06.2016 um 11:58 schrieb Peter Maydell:
On 24 June 2016 at 10:37, Stefan Hajnoczi wrote:
> On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote:
On Fri, Jun 24, 2016 at 12:45:49PM +0200, Peter Lieven wrote:
> Am 24.06.2016 um 11:58 schrieb Peter Maydell:
> > On 24 June 2016 at 10:37, Stefan Hajnoczi wrote:
> >> On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote:
> >>> On 22 June 2016 at 20:55, Peter Lieven wrote:
> What ma
On Thu, Jun 23, 2016 at 11:57:45AM +0200, Peter Lieven wrote:
> Am 21.06.2016 um 15:18 schrieb Dr. David Alan Gilbert:
> > * Peter Lieven (p...@kamp.de) wrote:
> > > Hi,
> > >
> > > while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS
> > > memory usage has heavily increased.
>
Am 24.06.2016 um 11:58 schrieb Peter Maydell:
> On 24 June 2016 at 10:37, Stefan Hajnoczi wrote:
>> On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote:
>>> On 22 June 2016 at 20:55, Peter Lieven wrote:
What makes the coroutine pool memory intensive is the stack size of 1MB per
>>>
* Peter Lieven (p...@kamp.de) wrote:
> Am 24.06.2016 um 11:37 schrieb Stefan Hajnoczi:
> > On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote:
> >> On 22 June 2016 at 20:55, Peter Lieven wrote:
> >>> What makes the coroutine pool memory intensive is the stack size of 1MB
> >>> per
> >>
On 24 June 2016 at 10:37, Stefan Hajnoczi wrote:
> On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote:
>> On 22 June 2016 at 20:55, Peter Lieven wrote:
>> > What makes the coroutine pool memory intensive is the stack size of 1MB per
>> > coroutine. Is it really necessary to have such a
Am 24.06.2016 um 11:37 schrieb Stefan Hajnoczi:
> On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote:
>> On 22 June 2016 at 20:55, Peter Lieven wrote:
>>> What makes the coroutine pool memory intensive is the stack size of 1MB per
>>> coroutine. Is it really necessary to have such a big
On Wed, Jun 22, 2016 at 09:56:06PM +0100, Peter Maydell wrote:
> On 22 June 2016 at 20:55, Peter Lieven wrote:
> > What makes the coroutine pool memory intensive is the stack size of 1MB per
> > coroutine. Is it really necessary to have such a big stack?
>
> That reminds me that I was wondering i
Am 24.06.2016 um 10:20 schrieb Paolo Bonzini:
>
> On 24/06/2016 10:11, Peter Lieven wrote:
>> Am 24.06.2016 um 06:10 schrieb Paolo Bonzini:
> If it's 10M nothing. If there is a 100M regression that is also caused
> by RCU, we have to give up on it for that data structure, or mmap/munmap
>>
On 24/06/2016 10:11, Peter Lieven wrote:
> Am 24.06.2016 um 06:10 schrieb Paolo Bonzini:
If it's 10M nothing. If there is a 100M regression that is also caused
by RCU, we have to give up on it for that data structure, or mmap/munmap
the affected data structures.
>>> If it was only
Am 24.06.2016 um 06:10 schrieb Paolo Bonzini:
>>> If it's 10M nothing. If there is a 100M regression that is also caused
>>> by RCU, we have to give up on it for that data structure, or mmap/munmap
>>> the affected data structures.
>> If it was only 10MB I would agree. But if I run the VM describe
> > If it's 10M nothing. If there is a 100M regression that is also caused
> > by RCU, we have to give up on it for that data structure, or mmap/munmap
> > the affected data structures.
>
> If it was only 10MB I would agree. But if I run the VM described earlier
> in this thread it goes from ~35
Am 23.06.2016 um 18:53 schrieb Paolo Bonzini:
>
> On 23/06/2016 18:19, Peter Lieven wrote:
>> Mhh, so your idea could be right. But what to do now? The introduction
>> of RCU obviously increases the short term RSS usage. But thats never
>> corrected as it seems.
>>
>> I see this behaviour with kern
On 23/06/2016 18:19, Peter Lieven wrote:
> Mhh, so your idea could be right. But what to do now? The introduction
> of RCU obviously increases the short term RSS usage. But thats never
> corrected as it seems.
>
> I see this behaviour with kernel 3.19 and kernel 4.4
If it's 10M nothing. If the
Am 23.06.2016 um 17:47 schrieb Paolo Bonzini:
On 23/06/2016 17:31, Peter Lieven wrote:
Am 23.06.2016 um 17:21 schrieb Paolo Bonzini:
On 23/06/2016 16:58, Peter Lieven wrote:
commit ba3f4f64b0e941b9e03568b826746941bef071f9
Author: Paolo Bonzini
Date: Wed Jan 21 12:09:14 2015 +0100
ex
On 23/06/2016 17:31, Peter Lieven wrote:
> Am 23.06.2016 um 17:21 schrieb Paolo Bonzini:
>>
>> On 23/06/2016 16:58, Peter Lieven wrote:
>>> commit ba3f4f64b0e941b9e03568b826746941bef071f9
>>> Author: Paolo Bonzini
>>> Date: Wed Jan 21 12:09:14 2015 +0100
>>>
>>> exec: RCUify AddressSpaceD
Am 23.06.2016 um 17:21 schrieb Paolo Bonzini:
On 23/06/2016 16:58, Peter Lieven wrote:
commit ba3f4f64b0e941b9e03568b826746941bef071f9
Author: Paolo Bonzini
Date: Wed Jan 21 12:09:14 2015 +0100
exec: RCUify AddressSpaceDispatch
Note that even after this patch, most callers of add
On 23/06/2016 16:58, Peter Lieven wrote:
> commit ba3f4f64b0e941b9e03568b826746941bef071f9
> Author: Paolo Bonzini
> Date: Wed Jan 21 12:09:14 2015 +0100
>
> exec: RCUify AddressSpaceDispatch
>
> Note that even after this patch, most callers of address_space_*
> functions must st
Am 23.06.2016 um 17:00 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Am 21.06.2016 um 15:18 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi,
while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS memory
usage has heavily increase
Am 21.06.2016 um 15:18 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi,
while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS memory
usage has heavily increased.
We use hugepages so the RSS memory does not include VM memory. In Qemu 2.2.0 it
used to be
* Peter Lieven (p...@kamp.de) wrote:
> Am 21.06.2016 um 15:18 schrieb Dr. David Alan Gilbert:
> > * Peter Lieven (p...@kamp.de) wrote:
> > > Hi,
> > >
> > > while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS
> > > memory usage has heavily increased.
> > > We use hugepages so t
Am 21.06.2016 um 15:18 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi,
while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS memory
usage has heavily increased.
We use hugepages so the RSS memory does not include VM memory. In Qemu 2.2.0 it
used to be
On 22 June 2016 at 20:55, Peter Lieven wrote:
> What makes the coroutine pool memory intensive is the stack size of 1MB per
> coroutine. Is it really necessary to have such a big stack?
That reminds me that I was wondering if we should allocate
our coroutine stacks with MAP_GROWSDOWN (though if w
Am 22.06.2016 um 12:56 schrieb Stefan Hajnoczi:
> On Tue, Jun 21, 2016 at 05:12:57PM +0200, Peter Lieven wrote:
>> - We changed the coroutine pool to a per thread model. I disabled the pool.
>> This seems
>>to cut the max used RSS to about 150MB which is still a lot more than
>> qemu-2.2.0
>
On Tue, Jun 21, 2016 at 05:12:57PM +0200, Peter Lieven wrote:
> - We changed the coroutine pool to a per thread model. I disabled the pool.
> This seems
>to cut the max used RSS to about 150MB which is still a lot more than
> qemu-2.2.0
The per-thread coroutine pools only grow when a thread
Am 21.06.2016 um 15:18 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi,
while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS memory
usage has heavily increased.
We use hugepages so the RSS memory does not include VM memory. In Qemu 2.2.0 it
used to be
* Peter Lieven (p...@kamp.de) wrote:
> Hi,
>
> while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS memory
> usage has heavily increased.
> We use hugepages so the RSS memory does not include VM memory. In Qemu 2.2.0
> it used to be ~30MB per vServer
> and increased to up to 30
Hi,
while upgrading from Qemu 2.2.0 to Qemu 2.5.1.1 I noticed that the RSS memory
usage has heavily increased.
We use hugepages so the RSS memory does not include VM memory. In Qemu 2.2.0 it
used to be ~30MB per vServer
and increased to up to 300 - 400MB for Qemu 2.5.1.1 (same with master). The
28 matches
Mail list logo
