Messages in this thread | | | From | David Laight <> | Subject | RE: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic() | Date | Mon, 15 Jun 2020 11:22:35 +0000 |
| |
From: Al Viro > Sent: 13 June 2020 16:31 > On Sat, Jun 13, 2020 at 07:12:36PM +0530, afzal mohammed wrote: > > Hi, > > > > On Sat, Jun 13, 2020 at 01:56:15PM +0100, Al Viro wrote: > > > > > Incidentally, what about get_user()/put_user()? _That_ is where it's > > > going to really hurt... > > > > All other uaccess routines are also planned to be added, posting only > > copy_{from,to}_user() was to get early feedback (mentioned in the > > cover letter) > > Sure, but what I mean is that I'd expect the performance loss to be > dominated by that, not by copy_from_user/copy_to_user on large amounts > of data. Especially on the loads like kernel builds - a lot of stat() > and getdents() calls there.
Or any network traffic where the number of usercopies involved in, for example, sendmsg() gives a measurable performance decrease when HARDENED_USERCOPY is enabled.
Do you have issues with cache aliasing? (Is aliasing the right term?) Where potentially the temporary kernel map doesn't use the same cache lines as the user processes map.
I'm not sure what problem you are trying to solve, but for 64bit systems it may be possible to map all of physical memory into the kernel address map, them you (loosely) only have to find the KVA that matches the user-VA to do the copy.
IIRC our SYSV kernels used to do that - until we had 384MB of physical memory and ran out of kernel address space.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |