From: Dmitry Torokhov on
On Tue, Apr 06, 2010 at 09:32:47AM -0700, Avi Kivity wrote:
> On 04/06/2010 01:58 AM, Dmitry Torokhov wrote:
> >
> >> Also please explain the applicability of this driver. Will xen use it?
> >> kvm? Out-of-tree code?
> >>
> > The driver is expected to be used on VMware platform - mainly ESX.
> > Originally we tried to converge with KVM and use virtio and
> > stock virtio_balloon driver but Avi mentioned that our code emulating
> > virtqueue was more than balloon code itself and thus using virtio did
> > not make nuch sense.
> >
>
> Yeah. If we wanted commonality, we could make a balloon_core.c that
> contains the common code. IMO that's premature, but perhaps there's

I really not sure if it makes much sense. Ripping out virtdev/virtqueue
from virtio_balloon leaves pretty much nothing.

> some meat there (like suspend/resume support and /proc//sys interface).

We do not need any special suspend/resume support - the freezeable
workqueue is stopped when suspending.

Thanks.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on
On 04/06/2010 02:34 AM, Andrew Morton wrote:
> On Mon, 05 Apr 2010 16:28:38 -0700
> Jeremy Fitzhardinge<jeremy(a)goop.org> wrote:
>
>
>> And is there some way to get the vm subsystem to provide backpressure:
>> "I'm getting desperately short of memory!"?
>>
> Not really. One could presumably pull dopey tricks by hooking into
> slab shrinker registration or even ->writepage(). But cooking up
> something explicit doesn't sound too hard - the trickiest bit would be
> actually defining what it should do.
>

The oft-suggested approach is to look at the I/O load from guests and
give more memory to those that are thrashing. Of course not all I/O is
directly due to memory pressure.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dan Magenheimer on
> From: Avi Kivity [mailto:avi(a)redhat.com]
> Sent: Tuesday, April 06, 2010 10:31 AM
> >
> >> And is there some way to get the vm subsystem to provide
> backpressure:
> >> "I'm getting desperately short of memory!"?
> >>
> > Not really. One could presumably pull dopey tricks by hooking into
> > slab shrinker registration or even ->writepage(). But cooking up
> > something explicit doesn't sound too hard - the trickiest bit would
> be
> > actually defining what it should do.
>
> The oft-suggested approach is to look at the I/O load from guests and
> give more memory to those that are thrashing. Of course not all I/O is
> directly due to memory pressure.

Which is why it is very useful to be able to differentiate between:
1) refault I/O (due to pagecache too small, and PFRA choices)
2) swap I/O (due to memory pressure)
3) normal file dirty writes (due to an app's need for persistence)

Again, the cleancache and frontswap hooks and APIs separate these
out nicely.

Dan "who worries he is sounding like a broken record"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on
On 04/06/2010 08:06 PM, Dmitry Torokhov wrote:
>
>> some meat there (like suspend/resume support and /proc//sys interface).
>>
> We do not need any special suspend/resume support - the freezeable
> workqueue is stopped when suspending.
>

Ah, virtio_balloon should do the same.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on
On 04/06/2010 09:32 AM, Avi Kivity wrote:
> Yeah. If we wanted commonality, we could make a balloon_core.c that
> contains the common code. IMO that's premature, but perhaps there's
> some meat there (like suspend/resume support and /proc//sys interface).

I think it would be useful to have common:

1. User and kernel mode ABIs for controlling ballooning. It assumes
that the different balloon implementations are sufficiently
similar in semantics. (Once there's a kernel ABI, adding a
common user ABI is trivial.)
2. Policy driving the ballooning driver, at least from the guest
side. That is, some good metrics from the vm subsystem about
memory pressure (both positive and negative), and something to
turn those metrics into requests to the balloon driver.

1) is not a huge amount of code, but something consistent would be
nice. 2) is something we've been missing and is a bit of an open
question/research project anyway.

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/