[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] xen/sched: rework credit2 run-queue allocation
On 19.02.20 19:37, Dario Faggioli wrote:
On Wed, 2020-02-19 at 17:52 +0100, Jan Beulich wrote:
On 19.02.2020 17:47, Dario Faggioli wrote:
On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -849,51 +822,71 @@ static inline bool same_core(unsigned int
cpua,
unsigned int cpub)
cpu_to_core(cpua) == cpu_to_core(cpub);
}
-static unsigned int
-cpu_to_runqueue(const struct csched2_private *prv, unsigned int
cpu)
+static struct csched2_runqueue_data *
+cpu_add_to_runqueue(struct csched2_private *prv, unsigned int
cpu)
{
- const struct csched2_runqueue_data *rqd;
- unsigned int rqi;
+ struct csched2_runqueue_data *rqd, *rqd_new;
+ struct list_head *rqd_ins;
+ unsigned long flags;
+ int rqi = 0;
+ bool rqi_unused = false, rqd_valid = false;
+
+ rqd_new = xzalloc(struct csched2_runqueue_data);
So, I'm not sure I see why it's better to allocating this here, and
then free it if we didn't need it, instead than allocating it
later,
only if we actually need it... What am I missing? :-)
Where possible we should try to avoid calling allocation functions
with locks held.
Ah, sure, that's a very good reason indeed, my bad not noticing that
doing this like that the allocation sits outside of the write_lock()
section.
Nevertheless, I'd add a quick comment about that, to make it even more
obvious. :-)
Do we really need that?
Calling any of the alloc functions with interrupts off will crash the
system (at least in debug builds).
I don't think we want to add such comments all over the code.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
