[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACSApvZU0o3MSp33G0Ld+1dr-k82UCcJqF=40AVL-F6UXHpGgg@mail.gmail.com>
Date: Thu, 1 Dec 2022 13:39:37 -0500
From: Soheil Hassas Yeganeh <soheil@...gle.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Willem de Bruijn <willemb@...gle.com>,
Shakeel Butt <shakeelb@...gle.com>
Subject: Re: [PATCH 6/6] eventpoll: add support for min-wait
On Thu, Dec 1, 2022 at 1:00 PM Jens Axboe <axboe@...nel.dk> wrote:
>
> >>> @@ -1845,6 +1891,18 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
> >>> ewq.timed_out = true;
> >>> }
> >>>
> >>> + /*
> >>> + * If min_wait is set for this epoll instance, note the min_wait
> >>> + * time. Ensure the lowest bit is set in ewq.min_wait_ts, that's
> >>> + * the state bit for whether or not min_wait is enabled.
> >>> + */
> >>> + if (ep->min_wait_ts) {
> >>
> >> Can we limit this block to "ewq.timed_out && ep->min_wait_ts"?
> >> AFAICT, the code we run here is completely wasted if timeout is 0.
> >
> > Yep certainly, I can gate it on both of those conditions.
> Looking at this for a respin, I think it should be gated on
> !ewq.timed_out? timed_out == true is the path that it's wasted on
> anyway.
Ah, yes, that's a good point. The check should be !ewq.timed_out.
Thanks,
Soheil
> --
> Jens Axboe
>
Powered by blists - more mailing lists