ia64/linux-2.6.18-xen.hg

view Documentation/networking/filter.txt @ 897:329ea0ccb344

balloon: try harder to balloon up under memory pressure.

Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).

However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.

This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.

Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Jun 05 14:01:20 2009 +0100 (2009-06-05)
parents 831230e53067
children
line source
1 filter.txt: Linux Socket Filtering
2 Written by: Jay Schulist <jschlst@samba.org>
4 Introduction
5 ============
7 Linux Socket Filtering is derived from the Berkeley
8 Packet Filter. There are some distinct differences between
9 the BSD and Linux Kernel Filtering.
11 Linux Socket Filtering (LSF) allows a user-space program to
12 attach a filter onto any socket and allow or disallow certain
13 types of data to come through the socket. LSF follows exactly
14 the same filter code structure as the BSD Berkeley Packet Filter
15 (BPF), so referring to the BSD bpf.4 manpage is very helpful in
16 creating filters.
18 LSF is much simpler than BPF. One does not have to worry about
19 devices or anything like that. You simply create your filter
20 code, send it to the kernel via the SO_ATTACH_FILTER ioctl and
21 if your filter code passes the kernel check on it, you then
22 immediately begin filtering data on that socket.
24 You can also detach filters from your socket via the
25 SO_DETACH_FILTER ioctl. This will probably not be used much
26 since when you close a socket that has a filter on it the
27 filter is automagically removed. The other less common case
28 may be adding a different filter on the same socket where you had another
29 filter that is still running: the kernel takes care of removing
30 the old one and placing your new one in its place, assuming your
31 filter has passed the checks, otherwise if it fails the old filter
32 will remain on that socket.
34 Examples
35 ========
37 Ioctls-
38 setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
39 setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
41 See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
42 Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.