Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

poller没有区分提交的是读还是写请求问题 #17

Open
longzhiri opened this issue Jun 11, 2021 · 9 comments
Open

poller没有区分提交的是读还是写请求问题 #17

longzhiri opened this issue Jun 11, 2021 · 9 comments

Comments

@longzhiri
Copy link

你好! 我在看代码发现gaio会不区分读写请求,统一都向poller注册EPOLLIN和EPOLLOUT事件,这样会有个问题,比如echo server中在等客户端发数据过来前,会因为这条链接可写被不断唤醒,空转CPU,不知道你怎么看这个问题。

@xtaci
Copy link
Owner

xtaci commented Jun 11, 2021

不会被”不断唤醒“, 因为有EPOLLONESHOT

@longzhiri
Copy link
Author

因为你readers不为空,会一直Rearm,重现步骤是:启动echo server,客户端发起连接,但是不发任何数据。

@xtaci
Copy link
Owner

xtaci commented Jun 11, 2021

因为你readers不为空,会一直Rearm,重现步骤是:启动echo server,客户端发起连接,但是不发任何数据。

仔细看代码

@longzhiri
Copy link
Author

这是我启动echo_server, telnet 连接上去,CPU的占用
image

@xtaci
Copy link
Owner

xtaci commented Jun 11, 2021

这是我启动echo_server, telnet 连接上去,CPU的占用
image

看到了,确实有这个问题。

xtaci added a commit that referenced this issue Jun 11, 2021
@xtaci
Copy link
Owner

xtaci commented Jun 11, 2021

fix了

@longzhiri
Copy link
Author

还有个问题,我注意到你使用了EPOLLONESHOT|EPOLLET方式添加到epoll,但是每次从fd读数据(tryRead函数)并没有保证读干净(一直读到EAGAIN)。比如客户端向服务端发送7K数据并停止,服务端内核buffer中立即收到了7K数据,这时发起一个异步读请求ReadFull 4K数据能返回,但是后面只要客户端不再发数据,因为ET模式的缘故,就再也不会唤醒读了,导致剩余3K数据读不到。

@xtaci
Copy link
Owner

xtaci commented Jun 11, 2021

还有个问题,我注意到你使用了EPOLLONESHOT|EPOLLET方式添加到epoll,但是每次从fd读数据(tryRead函数)并没有保证读干净(一直读到EAGAIN)。比如客户端向服务端发送7K数据并停止,服务端内核buffer中立即收到了7K数据,这时发起一个异步读请求ReadFull 4K数据能返回,但是后面只要客户端不再发数据,因为ET模式的缘故,就再也不会唤醒读了,导致剩余3K数据读不到。

不会

@lesismal
Copy link

lesismal commented Jun 1, 2022

除了EPOLLONESHOT确实没法不浪费重复触发并反向传导流控,但是EPOLLONESHOT的syscall更多也确实是浪费性能,我最初只用EPOLLLT没支持EPOLLET,后来增加了支持,但是没支持EPOLLONESHOT,最近也在琢磨可不可以折衷一点,EPOLLET不带EPOLLONESHOT,fd上带个当前state、如果已经可读则不重复派发给应用,标准库似乎就是这种但runtime还自带了调度。
通常情况下交互,EPOLLET的未读完时新数据到来导致重复事件的浪费情况很少,kcptun这种隧道性质的跟普通的业务应用相比确实是特殊场景。
如果是kcptun这种,EPOLLET即使重复派发但应用层仍然根据流控的反向传导来决定要不要读,即使重发派发了其实应该也还好,被反向流控时等待了,系统本来也就不繁忙,所以即使多触发几次事件也不会太影响吞吐
而对于普通应用每个conn其实重复触发的概率很低,所以也不太会影响吞吐

所以要不要考虑下去掉EPOLLONESHOT?去掉的话,真正跑很高量的场景下,省掉的syscall可能会让吞吐好于现在的

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants