Hello, On Tue, Jul 30, 2019 at 04:16:58PM +0800, yebiaoxiang wrote: > For single work, the order can guaranteed already, single work will only > queued on single pwq at a time. The challenge is how to guarantee the order > between different works, they may queued on different pwqs, and executed > by each worker without synchronizing. > > One of immature scheme is add two members enqueue_num and process_num to WQ, > when a task enqueue in function __queue_work, save the enqueue_num to task, > and then increase enqueue_num. When process_one_work check the enqueue_num of > work whether equal with current_num or not. Keep waitting if false, if true > then execute the work and increase current_num after done. > like below:
So, I'd much preper if this is something which is implemented in front of the core logic. e.g. build a separate pre-queue to order the work items. > This immature scheme seems still too ugly, I tested it and got a smack in the > eye. > So is there any good idea to making ordered workqueues numa-aware faultlessly? > BTW, I have no idea if is necessary to guarantee the order between different > works. That said, if strict ordering isn't an requirement, just using unordered workqueue where each work item is grabbing mutex would be enough, right? Thanks. -- tejun -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/20190805180504.GH136335%40devbig004.ftw2.facebook.com.
