[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210107185559.GI3579531@ZenIV.linux.org.uk>
Date: Thu, 7 Jan 2021 18:55:59 +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 06:40:58PM +0000, Al Viro wrote:
> do_sys_poll(): do the wholesale copyout
>
> Don't bother with patching up just one field - 16 bits out of each 64.
> The amount of memory traffic is not going to be greater (might be
> smaller, actually) and the loop in copy_to_user() is optimized for
> bulk copy.
BTW, considering the access pattern, I would expect it to be
considerably cheaper in a lot of cases; basically, we have a copy
of userland array of 64bit values, then we do a non-trivial amount
of work and modify 16 bits out of each 64. Then we want that
propagated back to the original array. I suspect that copying just
those 16bit fields out is going to cost more that a bulk copy of
the entire thing, and not just on s390 and similar oddball cases.
Comments?
Powered by blists - more mailing lists