On 08/20/2013 03:09 PM, Michal Privoznik wrote:
> On 20.08.2013 14:11, Ján Tomko wrote:
>> On 08/20/2013 11:10 AM, Michal Privoznik wrote:
>>> Since 16bcb3 we have a regression. The hard_limit is set
>>> unconditionally. By default, the limit is zero. Hence, if user hasn't
>>> configured any, we se
On 20.08.2013 14:11, Ján Tomko wrote:
> On 08/20/2013 11:10 AM, Michal Privoznik wrote:
>> Since 16bcb3 we have a regression. The hard_limit is set
>> unconditionally. By default, the limit is zero. Hence, if user hasn't
>> configured any, we set the zero in cgroup subsystem making the kernel
>> ki
On 08/20/2013 11:10 AM, Michal Privoznik wrote:
> Since 16bcb3 we have a regression. The hard_limit is set
> unconditionally. By default, the limit is zero. Hence, if user hasn't
> configured any, we set the zero in cgroup subsystem making the kernel
> kill the corresponding qemu process immediatel
On 08/20/13 12:08, Osier Yang wrote:
> On 20/08/13 17:10, Michal Privoznik wrote:
>> Since 16bcb3 we have a regression. The hard_limit is set
>> unconditionally. By default, the limit is zero. Hence, if user hasn't
s/default,/default/
>> configured any, we set the zero in cgroup subsystem making
On 20/08/13 17:10, Michal Privoznik wrote:
Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
configured any, we set the zero in cgroup subsystem making the kernel
kill the corresponding qemu process immediately. The prop
Since 16bcb3 we have a regression. The hard_limit is set
unconditionally. By default, the limit is zero. Hence, if user hasn't
configured any, we set the zero in cgroup subsystem making the kernel
kill the corresponding qemu process immediately. The proper fix is to
set hard_limit iff user has conf