On 2023/06/23 18:45, Sebastian Andrzej Siewior wrote: > On 2023-06-23 00:43:00 [+0900], Tetsuo Handa wrote: >> On 2023/06/23 0:04, Petr Mladek wrote: >>> AFAIK, rt_spin_lock(lock) fulfills exactly the above requirements. >>> The owner could schedule. The waiter could schedule as well so that >>> they could be running on the same CPU. Also the current owner gets >>> higher priority when the is a waiter with the higher priority to avoid >>> the priority inversion. >> >> Excuse me, but that is about multiple threads trying to acquire the same lock, isn't it? >> >> Our case is that one thread which makes zonelist_update_seq.seqcount odd acquires >> zonelist_update_seq.lock but threads spinning at >> read_seqbegin(zonelist_update_seq.seqcount) from zonelist_iter_begin() do nothing but >> cpu_relax() busy loop. There is no way to teach that these threads need to give >> CPU to the thread which made zonelist_update_seq.seqcount odd... > > For !RT there is no spinning because interrupts are disabled. > For RT there is no spinning because the reader blocks on lock owned by > writer. My understanding is that zonelist_iter_begin() accesses only zonelist_update_seq.seqcount . From where is the zonelist_update_seq.lock accessed when zonelist_iter_begin() is called?
