|
On Sat, Aug 13, 2022 at 03:11:48PM +0300, Julian Anastasov wrote:
> > The intention is to develop this RFC patch into a short series addressing
> > the design changes proposed in [1]. Also, after moving the rate estimation
> > out of softirq context, the whole estimator list could be processed
> > concurrently - more than one work item would be used.
>
> Other developers tried solutions with workqueues
> but so far we don't see any results. Give me some days, may be
> I can come up with solution that uses kthread(s) to allow later
> nice/cpumask cfg tuning and to avoid overload of the system
> workqueues.
The RFC patch already resolves the issue despite having the code still run in
softirq context. Even if estimators were processed in groups, moving the rate
estimation out of softirq context is a good idea. I am interested in
implementing this. An alternative approach would be moving the rate estimation
out of softirq context and reworking locking so that cond_resched() could be
used to let other processes run as the scheduler sees fit. I would be willing
to try to implement this alternative approach as well.
Jiri Wiesner
SUSE Labs
|
