RE: Linux balloon driver stops accepting target_kb for a long time

["Jan Beulich" <JBeulich@novell.com>]

>>> On 25.08.10 at 00:38, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> Well the 1 vcpu system is very busy doing a "make -j64" and there's
> a high amount of swap activity.  What priority does balloon_worker
> (launched with schedule_work()) have relative to userland
> threads and other kernel threads such as kswapd?  I.e. is
> it possible that it gets locked out for 30 minutes?  It appears
> that the new balloon target is applied only when system activity
> goes way down (when the number of cc1's run from make starts
> going down).

It should be running in one of the events/<number> worker threads,
which appear to get priority adjusted only in the RT case. It wouldn't
seem right for that thread to get starved for 30 min, but then again
running a "make -j64" on a 1-vCPU and too-little-memory system
seems questionable in the first place.

> Is there any way to boost the priority of this thread?
> Also, if it matters, the "make -j64" is launched from /etc/rc.local,
> so might that boost the priority of the "userland" threads?

I don't think so for both items.

>> I think SysRq-t would also allow you to check whether
>> balloon_process() indeed doesn't exit over a period of minutes
> 
> This was a good idea, but I haven't yet gotten a full SysRq-t
> output because there are so many processes running and I think
> the SysRq-t adds to the general chaos... When I use it, the
> guest goes into 100% vcpu usage after the "make -j64" is
> complete. :-(  However, I can ssh in and top shows the
> thread "events/0" using nearly 100% of the cpu.
>
> Assuming I get a good SysRq-t, would I simply be looking for
> a process stack dump with balloon_process in the stack?
> Would this kind of a yielded kernel thread even show up in
> SysRq-t output?

Hmm, since this is a single vCPU VM, it would be unavoidable
for it to run in the same thread as the balloon worker. As a
result you wouldn't be able to see any trace of it...

Jan