This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
On 23/5/08 18:01, "Ben Guthro" <bgut...@virtualiron.com> wrote:
Yes, sorry - should have removed our terminology from the description.
Node=physical machine
VS=HVM guest w/ pv-on-hvm drivers
Looking back at the original bug report - it seems to indicate it was
migrating from a system with 2 processors to one with 8
It¹s very surprising that lock contention would cause such a severe lack of
progress on an 8-CPU system. If the lock is that hotly contended then even
the usage of it in free_domheap_pages() has to be questionable.
I¹m inclined to say that if we want to address this then we should do it in
one or more of the following ways:
1. Count CPUs into the scrub function with an atomic_t and beyond a limit
all other CPUs bail straight out after re-setting their timer.
2. Increase scrub batch size to reduce proportion of time that each loop
iteration holds the lock.
3. Turn the spin_lock() into a spin_trylock() so that the timeout check can
be guaranteed to execute frequently.
4. Eliminate the global lock by building a lock-free linked list, or by
maintaining per-CPU hashed work queues with work stealing, or... etc.
The patch as-is at least suffers from the issue that the primary scrubber¹
should be regularly checking for softirq work. But I¹m not sure such a
sizeable change to the scheduling policy for scrubbing (such as it is!) is
necessary or desirable.
Option 4 is on the morally highest ground but is of course the most work.
:-)
-- Keir
4 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH] scrub pages o...
.patch