| Message ID | 20181129184532.22553-1-blp@ovn.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [ovs-dev] unixctl: Avoid 100% CPU for slowly processed requests with another queued. | expand |
> On Nov 29, 2018, at 10:45 AM, Ben Pfaff <blp@ovn.org> wrote: > > If another request came in on a particular connection while the previous > request was still being processed, unixctl_server_wait() would wake up the > main loop but unixctl_server_run() wouldn't read the request, resulting in > 100% CPU use. > > I doubt whether this is a real problem because it's unusual for a client > to attempt to make requests in parallel. I found it while pursuing a 100% > CPU issue but it turned out not to be a bug (the 100% CPU was caused by > a client making requests as fast as possible). > > Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Justin Pettit <jpettit@ovn.org> --Justin
On Sat, Dec 01, 2018 at 01:26:33PM -0800, Justin Pettit wrote: > > > On Nov 29, 2018, at 10:45 AM, Ben Pfaff <blp@ovn.org> wrote: > > > > If another request came in on a particular connection while the previous > > request was still being processed, unixctl_server_wait() would wake up the > > main loop but unixctl_server_run() wouldn't read the request, resulting in > > 100% CPU use. > > > > I doubt whether this is a real problem because it's unusual for a client > > to attempt to make requests in parallel. I found it while pursuing a 100% > > CPU issue but it turned out not to be a bug (the 100% CPU was caused by > > a client making requests as fast as possible). > > > > Signed-off-by: Ben Pfaff <blp@ovn.org> > > Acked-by: Justin Pettit <jpettit@ovn.org> Thanks, applied to master.
diff --git a/lib/unixctl.c b/lib/unixctl.c index 730bd043a9ff..0bcfada9187d 100644 --- a/lib/unixctl.c +++ b/lib/unixctl.c @@ -409,7 +409,7 @@ unixctl_server_wait(struct unixctl_server *server) pstream_wait(server->listener); LIST_FOR_EACH (conn, node, &server->conns) { jsonrpc_wait(conn->rpc); - if (!jsonrpc_get_backlog(conn->rpc)) { + if (!jsonrpc_get_backlog(conn->rpc) && !conn->request_id) { jsonrpc_recv_wait(conn->rpc); } }
If another request came in on a particular connection while the previous request was still being processed, unixctl_server_wait() would wake up the main loop but unixctl_server_run() wouldn't read the request, resulting in 100% CPU use. I doubt whether this is a real problem because it's unusual for a client to attempt to make requests in parallel. I found it while pursuing a 100% CPU issue but it turned out not to be a bug (the 100% CPU was caused by a client making requests as fast as possible). Signed-off-by: Ben Pfaff <blp@ovn.org> --- lib/unixctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)