The following work is based on what Rik posted, with a few changes.
 the added requeue_task() is replaced with resched_task().
 there is no longer change by slice_remain() in schedule class.
 the schedule_hrtimeout() in KVM still plays its role, and it looks
nicer to move the searching of task out of kvm_vcpu_on_spin()
to be a function.
The compensation of yielded nanoseconds is not considered
or corrected in this work for both lender and borrower, but it looks
not a vulnerability since the lock contention is detected by CPU,
as Rik mentioned, and since both lender and borrower are marked
What scheduler should consider further for the PF_VCPU?
--- a/include/linux/sched.h 2010-11-01 19:54:12.000000000 +0800
+++ b/include/linux/sched.h 2011-01-02 18:09:38.000000000 +0800
@@ -1945,6 +1945,7 @@ static inline int rt_mutex_getprio(struc
extern void set_user_nice(struct task_struct *p, long nice);
extern int task_prio(const struct task_struct *p);
extern int task_nice(const struct task_struct *p);
+extern void yield_to(struct task_struct *, u64 *);
extern int can_nice(const struct task_struct *p, const int nice);
extern int task_curr(const struct task_struct *p);
extern int idle_cpu(int cpu);
--- a/kernel/sched.c 2010-11-01 19:54:12.000000000 +0800
+++ b/kernel/sched.c 2011-01-02 18:14:20.000000000 +0800
@@ -5151,6 +5151,42 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t
+ * Yield the CPU, giving the remainder of our time slice to task p.
+ * Typically used to hand CPU time to another thread inside the same
+ * process, eg. when p holds a resource other threads are waiting for.
+ * Giving priority to p may help get that resource released sooner.
+ * @nsecs: feedback to caller the nanoseconds yielded
+void yield_to(struct task_struct *p, u64 *nsecs)
+ unsigned long flags;
+ struct sched_entity *se = &p->se;
+ struct rq *rq;
+ struct cfs_rq *cfs_rq;
+ u64 ...
I threw out my patch before Christmas, replacing it with
Mike Galbraith's work.
Today I finally discovered why I had not been getting
very useful results testing the PLE code on the test
On this particular CPU model (Intel(R) Xeon(R) CPU X5670),
the value of ple_gap needs to be at least 48 !
A ple_gap value of 41 is simply too low to trigger reliably
with Avi's kvm-unit-tests PLE test and also only triggers
a few times a second at most (not too useful) with the other
tests I had been running...
All rights reversed
Now that I finally got useful test results (after
increasing ple_gap to be more useful on the X5670
CPU), I will post the patch series.
Christmas holidays are a good thing, but expect
patches tomorrow :)
All rights reversed