search for: credit1

Hey George, I was wondering if you could explain in simple terms how the scheduler would handle per-physical CPU when there are say 16 guests (each guest is using one VCPU), 32 physical CPUs and dom0 is not restricted to any CPUs. Would the scheduler per physical CPU schedule: guest, dom0, guest, dom0, and so on; or would it be more random? (I assume that both guest and dom0 would do a hypercall

Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> diff -r 4a4882df5649 -r 782284c5b1bc xen/common/sched_credit.c --- a/xen/common/sched_credit.c Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/common/sched_credit.c Thu Sep 01 16:29:50 2011 +0100 @@ -41,15 +41,9 @@ */ #define...

Hi, everyone, I''m curious about what are the differences between credit2 and credit1 of xen''s scheduler? And is credit2 will release in xen-4.1? Are there some one can tell me some details about them? or just tell me where can I find some reference about them? Thanks in advance :) -- - Luit @ Parallel Processing Institute, Fudan University ____________________________...

On Mon, Aug 28, 2017 at 8:04 AM, Alex Bradbury <asb at asbradbury.org> wrote: > On 27 August 2017 at 00:01, Alex Bradbury <asb at asbradbury.org> wrote: >> Hi all. I'm assuming most people reading this email are familiar with LLVM's >> code review process <http://llvm.org/docs/DeveloperPolicy.html#code-reviews> >> as well as LLVM Weekly, the

...ven pCPU, then as long as it has at least a certain amount of credit (currently defined as half of CSCHED_CREDIT_INIT, but more testing is needed to determine the best value) then it is chosen instead. This patch depends on Dario Faggioli''s patch set "Implement vcpu soft affinity for credit1" currently in version 5 for vcpu->cpu_hard_affinity and vcpu->cpu_soft_affinity defined in sched.h. --- Changes since v1: * fixed the check for soft affinity by adding a check for a full cpu_soft_affinity mask --- xen/common/sched_credit2.c | 32 +++++++++++++++++++++++++++++---...

As discussed in a previous e-mail, this patch series implements yield for the credit scheduler. This allows a VM to actually yield (give up the cpu to another VM) when it wants to. This has been shown to be effective when used in the spinlock code to avoid wasting time spinning when another vcpu is not currently scheduled. _______________________________________________ Xen-devel mailing list

...the link above: - xpin decreases startup time of vms in a bootstorm - xpin has a pathological case when the vms are burning lots of cpu - nopin produces an interesting cluster of high event channel latency between 100us-1000us when enough vms are using lots of cpu - experimental tweaks on the xen credit1 scheduler code that cause the xpin pathological case to go away, and other increases (and sometimes decreases) in bootstorm and vm density performance. cheers, Marcus

Hi all (and Mr. Dunlap in particular), I have a question about the credit (and ultimately credit2) scheduler that I hope you can help me with. I have read the white paper "Scheduler development update" and as much material on the credit scheduler as I can find, but I am still not completely clear on how I should think about the cap. Example scenario: Server hardware: 2

What are the outstanding things to do before we think we can start on the 4.2 -rc''s? Does anyone have a timetable in mind? hypervisor: * ??? - Keir, Tim, Jan? tools: * libxl stable API -- we would like 4.2 to define a stable API which downstream''s can start to rely on not changing. Aspects of this are: * event handling (IanJ working