Hello, I preferred to react to cleanup_net() faster and avoid creating threads if this is what we try to do here. Yes, removing _bh is correct. The risk is the other processes to spin if kthread is i
Hello, Yes Yes, wait/wakeup would be better alternative, it will avoid the possible priority inversion as Jiri noticed. Probably, the rate of rescheduling can be reduced, so that we can achieve sub-m
It would save some code to move the ipvs->enable check before the critical section and use a return statement right away. Per-CPU counters are updated from softirq context and read by user space proc
IIUC, this mutex_lock/unlock() is just used for waiting for the ipvs-e thread schedule back if it had been scheduled out in cond_resched_rcu() ? But not to protect data ? If so, I am wondering if we
Estimating all entries in single list in timer context causes large latency with multiple rules. Spread the estimator structures in multiple chains and use kthread(s) for the estimation. Every chain