> 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 (<[email protected]>) 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 > >
