----- Ursprüngliche Mail ----- > Von: "Benjamin Berg" <benja...@sipsolutions.net> >> While I acknowledge that time-travel itself is a beautiful hack, I'd >> like to keep the hacks >> to keep it working minimal. >> So, the problem here is that RCU callbacks never run and just pile up? > > Yes. A simple example of this is doing a "find /". This will allocate a > lot of inode information which is only free'ed at a later point. > >> I wonder why such a situation does not happen in a nohz_full setup on >> regular systems. > > Had to search for a bit. But, I think the boot CPU will still have a > tick even on a NOHZ_FULL setup. see the nohz_full= boot parameter. > > It does look like the RCU code might try to force scheduling (tiny RCU) > or wake up a worker (tree RCU) in these situations. But neither of > these attempts is going to fix the situation as there will be no call > to rcu_sched_clock_irq with time-travel.
Agreed. I think having a house keeping CPU (thread) will not work in time-travel mode. Kicking RCU whenever a syscall is executed is okay, the question is, are there other scenarios where RCU work can pile up and no syscall is run for a long time? Maybe we need to kick it at other places (page fault handler?) too. Thanks, //richard
