On Mon, 19 Oct 2009 10:34:16 +0100
George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
....
> Scalability for Xen past 8 logical processors (where 1 hyperthread is
> 1 schedulable unit) is likely to be poor, due to the load-balancing
> algorithm.
Yeah, I've been thinking in the back of my mind, some sort of multiple
runqueus, with vcpu priority adjustments with cpu usage, but at the same
time allow certain vcpus to maintain certain level of minimum usage. This
for cases where an app has pinned a high priority thread to a vcpu. I've
not looked at existing xen scheds, so may be it's already doing that. More
runqueues is less locking, but more load balancing, so may be something
that's tunable on the fly. Some thoughts at high level.....
> Regarding a Xen scheduler plug-in for DB applications, it seems to me
> it would be best to understand the characteristics of the DB workload
> and how they respond to different kinds of contention. There may be a
> few surprises; for example, a workload that you assumed was CPU-bound
> may in fact be making many qemu-handled operations, so it's really
> blocking thousands of times per second. If we can make the default
> scheduler handle DB workloads well without making a special plug-in,
> that would be preferrable.
Agree. I'm hoping to collect all that information over the next couple/few
months. The last attempt, made a year ago, didn't yield in a whole lot
of information because of problems with 32bit tools and 64bit guest apps
interaction.
In a nutshell, there's tremendous smarts in the DB, and so I think it
prefers a simplified schedular/OS that it can provide hints to and interact
a little with. Ideally, it would like ability for a privileged thread
to tell the OS/hyp, I want to yield cpu to thread #xyz.
Moreover, my focus is large, 32 to 128 logical processors, with 1/2
to 1TB memory. As such, I also want to address VCPUs being confined
to logical block of physical CPUs, taking into consideration that
licenses are per physical cpu core. Also, it's important for a
cluster heartbeat thread to get cpu at expected times, otherwise,
it starts to freak out. Apparently, we are seeing some of that during
live migrations. Waiting on more info on that myself.
> Would you be willing, if you have the time, to help "beta-test" a new
> scheduler with a DB workload and compare it to the old one?
Yeah, sure. I hope to have a setup in few weeks.
thanks,
Mukesh
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home