Jingyuan

The problem we encountered is similar to the problem solved in #264. When initing `iouringEngine`, we need to use `io_uring_prep_poll_multishot` to register fd for `cancel_wait`. However, our kernel does not...

When i use workerpool‘s `async_call` func to send async task, it may be call `cancel_wait`. On the latest branch, if you need to initialize the io_uring engine, it is necessary...

kernel version is 5.10, liburing version is 2.4. PhotonlibOS version is 0.8.2. Due to the higher version of liburing, we are able to initialize the io_uring engine and successfully register...

Using `io_uring_prep_write` + `io_uring_submit` seems infeasible because io_uring is not `thread-safe`, and the thread invoking cancel_wait is different from the VCPU, so locking is required for protection. However, if using...

> [@MJY-HUST](https://github.com/MJY-HUST) What kind of project are you developing with Photon? The underlying system is a database system

> > 第一次需要使用keytbale时构造，并赋值给task_meta.local_storage. keytable，task_meta析构时销毁keytable。 > > 我理解这是为了尽量复用、减少构造、不加锁。TaskMeta是从ResourcePool分配出来的，在进程运行的时候，不会释放TaskMeta的吧。那么一旦使用了KeyTable，TaskMeta就会绑定一个KeyTable，跟bthread_keytable_pool_t机制是不是有点兼容？例如一个TaskMeta已经绑定一个KeyTable，但是bthread_attr_t设置bthread_keytable_pool_t，这时候还需要额外的状态来记录KeyTable的来源用于处理归还逻辑吧。 > > 是不是用ObjectPool来分配KeyTable就能规避锁的影响，实现还简单？ 是的，前面说的逻辑和bthread_keytable_pool_t机制有重合。 感觉把bthread_keytable_pool_t替换为ObjectPool来管理KeyTable比较合适

使用bthread-local的场景是什么样的呢@lsdh-fei 在使用bthread-local变量时，如果create的bthread的addr中没有初始化bthread_keytable_pool_t的话，那么每次return_keytable都会直接析构keytable；另外如果初始化了bthread_keytable_pool_t的话，使用bthread-local变量时需要先调用bthread_getspecific尝试borrow_keytable进行复用，如果每次都是直接bthread_setspecific赋值的话，如果当前bthread不存在keytable的话，就会new一个新的keytable，内存就会不断增长，这个是之前就有的问题

是的，假设每个bthread都持有keytable的前提下，如果pendding的bthread数量过多(持续增长)，那么内存消耗是无法避免的。 如果是因为task调度的不均衡(极端情况下一个task group只执行需要创建/获取keytable的任务，然后yield，这些任务最终在其他的task group中执行完成)，那么也会出现内存持续增长的情况。这种情况下的一种解决方法是为每个task group的 tls keytable list的长度设置一个阈值，一旦超过之后加锁批量返回给一个全局链表；而当borrow_keytable失败需要new keytable时，先查看全局链表中是否有keytable，再加锁批量取一批，不直接new keytable。

> @MJY-HUST 10月节后会发新版本，能赶上新版本修复这个问题吗？ 周末修复一下，提个pr

我看现在parking_lot的数量是写死的，一个tag内只有四个；一旦worker数量多了，futex中锁的竞争就上来了，想问一下这个值改成一个可配的参数或者根据tag所属的worker总数来动态调大会有什么负面影响吗？（比如parking_lot的数量 = bthread_concurrency_by_tag / 4 or 8）。 我自己做了一些测试，除了上述的做法之外，减少无效的signal和在wait前先steal一次也能解决一部分问题。 相同的负载: 启动四个rpc_press ./rpc_press -proto=echo_c++/echo.proto -method=example.EchoService.Echo -input='{"message":"hello"}' -qps=100000 -server=0.0.0.0:8000 -timeout_ms=-1 服务端使用example/echo_c++中的，server，worker线程数量为64个，但是在服务内增加了使用bthread_start_background创建两个bthread来模拟触发signal的行为，优化前后： 前：    后：parking_lot改为16个