[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/55781: more rump fixes
No, Christos, the point is different here.
Only the bootstrap CPU calls rump_init() even after our change.
However, during rump_init() other CPUs are already scheduled some tasks,
so we need to wake them up, we cannot simply wait until rump_init()
finishes. If we wake them too early (i.e., before rump_init()), their
state will not be properly initialized yet. So, we need to wake them up
while in rump_init() but only *after* their state is fully initialized.
So, this is when the bootstrap CPU will call the callback function.
Note that other CPUs will not call rump_init(), they will simply
schedule some queued tasks.
Does it make sense?
On 11/4/20 10:43 AM, Christos Zoulas wrote:
On Nov 3, 2020, at 8:00 PM, Ruslan Nikolaev <nruslan_devel%yahoo.com@localhost
Thanks for the feedback! I'll see if I can fix it. In the meantime, I
also posted one more SMP-related patch: kern/55781
We also have rump (glue) files for new drivers such as ixgbe, nvme,
etc -- we will post them as well.
How does 55781 work? doesn't "rump_inited" prevent the function to be
entered from other cpus?
Main Index |
Thread Index |