On 04.09.19 15:48, Jan Beulich wrote:
On 09.08.2019 16:57, Juergen Gross wrote:
This prepares support of larger scheduling granularities, e.g. core
scheduling.
While at it move sched_has_urgent_vcpu() from include/asm-x86/cpuidle.h
into schedule.c removing the need for including sched-if.h in
cpuidle.h and multiple other C sources.
Looking again, the #include-s in .c files should have been unnecessary
altogether (and dropping of them could, if it was a separate patch, go
in right away), because of ...
Patch sent.
--- a/xen/include/asm-x86/cpuidle.h
+++ b/xen/include/asm-x86/cpuidle.h
@@ -4,7 +4,6 @@
#include <xen/cpuidle.h>
#include <xen/notifier.h>
#include <xen/sched.h>
-#include <xen/sched-if.h>
... this.
@@ -27,14 +26,4 @@ void update_idle_stats(struct acpi_processor_power *,
void update_last_cx_stat(struct acpi_processor_power *,
struct acpi_processor_cx *, uint64_t);
-/*
- * vcpu is urgent if vcpu is polling event channel
- *
- * if urgent vcpu exists, CPU should not enter deep C state
- */
-static inline int sched_has_urgent_vcpu(void)
-{
- return atomic_read(&this_cpu(schedule_data).urgent_count);
-}
And then, despite my previous ack, I'm slightly unhappy about this
very short function becoming an out-of-line one, when the only
users of it would preferably have as low latency as possible. I
don't suppose there's a way to keep it inline but still drop the
unwanted #include above?
The only alternatives I could think of are:
- Passing the "urgent" indicator via parameter to idle (you didn't
like that)
- Make urgent_count a plain percpu variable
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
