lkml.org 
[lkml]   [2018]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [lkp-robot] [fs] 3deb642f0d: will-it-scale.per_process_ops -8.8% regression
On Fri, Jun 22, 2018 at 02:33:07PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 22, 2018 at 01:17:22PM +0100, Al Viro wrote:
> > > The problem is that call to sk_busy_loop(), which is going to be indirect
> > > no matter what.
> >
> > if ->f_poll_head is NULL {
> > use ->poll
> > } else {
> > if can ll_poll (checked in ->f_mode)
> > call ->ll_poll(), if it returns what we want - we are done
> > add to ->f_poll_head
> > call ->poll_mask()
>
> What I have for now is slightly different:
>
> if ((events & POLL_BUSY_LOOP) && file->f_op->poll_busy_loop)
> file->f_op->poll_busy_loop(file, events);
>
> if (file->f_op->poll) {
> return file->f_op->poll(file, pt);
> } else if (file_has_poll_mask(file)) {
> ...
> }
>
> returns whatever we want part is something I want to look into
> once the basics are done as it probably is non entirely trivial due to
> structure of polling in the low-level network protocol.

First of all, you'll get the same ->f_op for *all* sockets. So you'll be
hitting that path regardless of sk_can_busy_loop(sock->sk). What's more,
that way you get (on fast path) even more indirect calls, AFAICS.

And I don't see any point in separate file_has_poll_mask() - just check
->f_poll_head and that's it.

\
 
 \ /
  Last update: 2018-06-22 14:30    [W:0.224 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site