view Documentation/sched-arch.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
line source
1 CPU Scheduler implementation hints for architecture specific code
3 Nick Piggin, 2005
5 Context switch
6 ==============
7 1. Runqueue locking
8 By default, the switch_to arch function is called with the runqueue
9 locked. This is usually not a problem unless switch_to may need to
10 take the runqueue lock. This is usually due to a wake up operation in
11 the context switch. See include/asm-ia64/system.h for an example.
13 To request the scheduler call switch_to with the runqueue unlocked,
14 you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file
15 (typically the one where switch_to is defined).
17 Unlocked context switches introduce only a very minor performance
18 penalty to the core scheduler implementation in the CONFIG_SMP case.
20 2. Interrupt status
21 By default, the switch_to arch function is called with interrupts
22 disabled. Interrupts may be enabled over the call if it is likely to
23 introduce a significant interrupt latency by adding the line
24 `#define __ARCH_WANT_INTERRUPTS_ON_CTXSW` in the same place as for
25 unlocked context switches. This define also implies
26 `__ARCH_WANT_UNLOCKED_CTXSW`. See include/asm-arm/system.h for an
27 example.
30 CPU idle
31 ========
32 Your cpu_idle routines need to obey the following rules:
34 1. Preempt should now disabled over idle routines. Should only
35 be enabled to call schedule() then disabled again.
37 2. need_resched/TIF_NEED_RESCHED is only ever set, and will never
38 be cleared until the running task has called schedule(). Idle
39 threads need only ever query need_resched, and may never set or
40 clear it.
42 3. When cpu_idle finds (need_resched() == 'true'), it should call
43 schedule(). It should not call schedule() otherwise.
45 4. The only time interrupts need to be disabled when checking
46 need_resched is if we are about to sleep the processor until
47 the next interrupt (this doesn't provide any protection of
48 need_resched, it prevents losing an interrupt).
50 4a. Common problem with this type of sleep appears to be:
51 local_irq_disable();
52 if (!need_resched()) {
53 local_irq_enable();
54 *** resched interrupt arrives here ***
55 __asm__("sleep until next interrupt");
56 }
58 5. TIF_POLLING_NRFLAG can be set by idle routines that do not
59 need an interrupt to wake them up when need_resched goes high.
60 In other words, they must be periodically polling need_resched,
61 although it may be reasonable to do some background work or enter
62 a low CPU priority.
64 5a. If TIF_POLLING_NRFLAG is set, and we do decide to enter
65 an interrupt sleep, it needs to be cleared then a memory
66 barrier issued (followed by a test of need_resched with
67 interrupts disabled, as explained in 3).
69 arch/i386/kernel/process.c has examples of both polling and
70 sleeping idle functions.
73 Possible arch/ problems
74 =======================
76 Possible arch problems I found (and either tried to fix or didn't):
78 h8300 - Is such sleeping racy vs interrupts? (See #4a).
79 The H8/300 manual I found indicates yes, however disabling IRQs
80 over the sleep mean only NMIs can wake it up, so can't fix easily
81 without doing spin waiting.
83 ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a)
85 sh64 - Is sleeping racy vs interrupts? (See #4a)
87 sparc - IRQs on at this point(?), change local_irq_save to _disable.
88 - TODO: needs secondary CPUs to disable preempt (See #1)