[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
unsigned int cpub)
             cpu_to_core(cpua) == cpu_to_core(cpub);
-static unsigned int
-cpu_to_runqueue(const struct csched2_private *prv, unsigned int
+static struct csched2_runqueue_data *
+cpu_add_to_runqueue(struct csched2_private *prv, unsigned int
-    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
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()

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.