Re: SMP work

[Almudena Garcia]

> That's really not supposed to happen. It could be useful to put printfs
> in thread_setrun in the if ((processor = th->bound_processor) ==
> PROCESSOR_NULL) case, which is not supposed to happen, to determine

> when we are actually getting there with such case.

Interesting tip. I'll try to experiment with this

> I had been looking at the linux code, it really isn't smp-safe, so we
> will need to keep ext2fs bound to cpu0 to avoid any kind of concurrency
> when it accesses the disk. It might even be useful to put some
> assertions to make sure that no code of linux/ is getting to run on
> cpu1.

Thanks by the info. I'll research about this

These days, I'm a bit busy, but I'll continue this project in a weeks

Thanks for your effort

El vie., 15 nov. 2019 a las 1:19, Samuel Thibault (<samuel.thibault@gnu.org>) escribió:

Hello,

Just a Re: on some IRC discussion. We were trying to set bound_processor
by default to cpu0 to make sure that everything happens on just one cpu
by default, to put things on cpu1 progressively. But that was leading to
ext2fs hanging. At some point it was mentioned that

“sometimes, default_pset.runq.runq.next.next shows the same thread than processor_ptr[0].runq.runq.next”

That's really not supposed to happen. It could be useful to put printfs
in thread_setrun in the if ((processor = th->bound_processor) ==
PROCESSOR_NULL) case, which is not supposed to happen, to determine
when we are actually getting there with such case.

I had been looking at the linux code, it really isn't smp-safe, so we
will need to keep ext2fs bound to cpu0 to avoid any kind of concurrency
when it accesses the disk. It might even be useful to put some
assertions to make sure that no code of linux/ is getting to run on
cpu1.

Samuel