[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210107183358.GG3579531@ZenIV.linux.org.uk>
Date: Thu, 7 Jan 2021 18:33:58 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: kernel test robot <oliver.sang@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
kernel test robot <lkp@...el.com>,
"Huang, Ying" <ying.huang@...el.com>,
Feng Tang <feng.tang@...el.com>, zhengjun.xing@...el.com
Subject: Re: [x86] d55564cfc2: will-it-scale.per_thread_ops -5.8% regression
On Thu, Jan 07, 2021 at 09:43:54AM -0800, Linus Torvalds wrote:
> Before, it would do the whole CLAC/STAC dance inside that loop for
> every entry (and with that commit d55564cfc22 it would be a function
> call, of course).
>
> Can you verify that this fixes the regression (and in fact I'd expect
> it to improve that test-case)?
I'm not sure it's the best approach, TBH. How about simply
for (walk = head; walk; ufds += walk->len, walk = walk->next) {
if (copy_to_user(ufds, walk->entries,
walk->len * sizeof(struct pollfd))
goto out_fds;
}
in there? It's both simpler (obviously matches the copyin side) and
might very well be faster...
Powered by blists - more mailing lists