From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D622C433E0 for ; Sat, 13 Jun 2020 20:45:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 42B472078A for ; Sat, 13 Jun 2020 20:45:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42B472078A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9EAF26B0003; Sat, 13 Jun 2020 16:45:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99BAE6B0005; Sat, 13 Jun 2020 16:45:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 88B966B0006; Sat, 13 Jun 2020 16:45:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id 6E4BF6B0003 for ; Sat, 13 Jun 2020 16:45:53 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 202431EF1 for ; Sat, 13 Jun 2020 20:45:53 +0000 (UTC) X-FDA: 76925370186.26.meal85_1710e6326de8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id F08CD1804B65A for ; Sat, 13 Jun 2020 20:45:52 +0000 (UTC) X-HE-Tag: meal85_1710e6326de8 X-Filterd-Recvd-Size: 6402 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Sat, 13 Jun 2020 20:45:52 +0000 (UTC) Received: from mail-qk1-f172.google.com ([209.85.222.172]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MNcYX-1jZWhZ2mZn-00P7GQ for ; Sat, 13 Jun 2020 22:45:50 +0200 Received: by mail-qk1-f172.google.com with SMTP id v79so12277852qkb.10 for ; Sat, 13 Jun 2020 13:45:50 -0700 (PDT) X-Gm-Message-State: AOAM5303oHEISC97hQANPUUiGXk5fHTfx86gUOqvW4JCMct3FvnDst9f ww5FcxoZAiyrcKzH1vXupsn5lPa1yAoWWfTo134= X-Google-Smtp-Source: ABdhPJzKWxg5VOCg6vbBkuAbhbaPgmzk/da3ldxe5pweVGVyYaX22A3xzHltoZ9K8pid2aVLjXRyBB04rgSXBEjgxrg= X-Received: by 2002:ae9:de85:: with SMTP id s127mr9295217qkf.352.1592081149191; Sat, 13 Jun 2020 13:45:49 -0700 (PDT) MIME-Version: 1.0 References: <9e1de19f35e2d5e1d115c9ec3b7c3284b4a4e077.1591885760.git.afzal.mohd.ma@gmail.com> <20200612135538.GA13399@afzalpc> <20200613120432.GA5319@afzalpc> In-Reply-To: <20200613120432.GA5319@afzalpc> From: Arnd Bergmann Date: Sat, 13 Jun 2020 22:45:33 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 1/3] lib: copy_{from,to}_user using gup & kmap_atomic() To: afzal mohammed Cc: Russell King - ARM Linux admin , Linus Walleij , "linux-kernel@vger.kernel.org" , Linux-MM , Linux ARM , Nicolas Pitre , Catalin Marinas , Will Deacon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:0zl5GFy3PNvZeFdDHcHbyf75zYNmmIbZmUPNZs6lgx8YKaNc+5X bbXT945nWSKd0OEv7r+A/ks7R/6w1LObxGr5fnC8ePG2gMNFQ6OQ/SEjXFSOmFfgSCPHCuZ 85elPoRIqdlwoTSFxBwu+o0YkAZg7vlG/4/Fn+wsmGFxBnRIHkGN7JingzFaqDsQ9gzfc3T R+elUFhnMaBlto7Wh24HQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:gLte3LU6/r8=:qmSmTHPNC8Ml77XRZs6m0G UXyDAzgNxmBqDN0XQMYE9Xk6TjoTmS9XNre7w9qpslUBZgLRfIuJKLjiFm00YOf8CnZbv5+ck EmRh1hUzsBHP4GoXwJpGuKlvEhrakGokeRG53C5rvj9SKsdqR0W7yew2FxoXuFEeIhtuGGcet 8HX/y9MslKNrIZbs8X4pXKsQEn8ASEpcwueryiNsiubxrYZjpZrai0zrpwVD1sxkmxO6lLnyp SrgkdiPPo5RSfTpbV4BT5WG7cVuq5qeYDRbXuF8/1/PNAt/z5s++BiZ5Ua05KeiNGgOsAotlE 1+Oo3WyQvNJrbFjpSAOiVVkLSIarGXc4XSpM/TnYhFyvmuS6hTtaNpeUSqaEhRr4zrv4zYBpZ rK37viA+qMFWit1QkOjBokbOlrXPgQW5G5YknZEaXGiJ1N1WmlQIAsYFmfTwCPK5+y079Gne4 L5Zkkz5xVDiCR1IOeVpDWf68+RNWO9wXZpzXODQ49/NzlKq85Y2PQNNnNx4VgI1bD3ibQPrbB URrLUMQF0DL1sN7/gOhmKo1s+ISlzL7FuxSDLHwj465405vD/MVC5FIMO69wRoEwzzBYpL9at OetPfhtToS5zV3gJtqEh0UC4t6y7tSN0hHzG19AZFjPeMOeiSIemPPs0bxMk90JDy6OH0/LSP IIVFDr3E+trQl0EXZHhdsFBV11XggC6bgRiTLp4nYuni4d0vWpSjneqMd6RTssafk3k3/2Xj5 oY9PUTKDdXyLjemIF/bQm3/wqYYwTVHiLixb6Dz+aF4BkusPIQjbkV2mAuDeTiDNBQkMFA8zp K+8UwK6cpj+oEpTrd0/OmYhCZ2RdUemHu8SVINrCXB8fAQO8ck= X-Rspamd-Queue-Id: F08CD1804B65A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Jun 13, 2020 at 2:04 PM afzal mohammed wr= ote: > On Fri, Jun 12, 2020 at 10:07:28PM +0200, Arnd Bergmann wrote: > > > I think a lot > > of usercopy calls are only for a few bytes, though this is of course > > highly workload dependent and you might only care about the large > > ones. > > Observation is that max. pages reaching copy_{from,to}_user() is 2, > observed maximum of n (number of bytes) being 1 page size. i think C > library cuts any size read, write to page size (if it exceeds) & > invokes the system call. Max. pages reaching 2, happens when 'n' > crosses page boundary, this has been observed w/ small size request > as well w/ ones of exact page size (but not page aligned). Right, this is apparently because tmpfs uses shmem_file_read_iter() to copy the file pages one at a time. generic_file_buffered_read() seems similar, to copying between an aligned kernel page and address in user space that is not page aligned would be an important case to optimize for. > Quickly comparing boot-time on Beagle Bone White, boot time increases > by only 4%, perhaps this worry is irrelevant, but just thought will > put it across. 4% boot time increase sounds like a lot, especially if that is only for copy_from_user/copy_to_user. In the end it really depends on how well get_user()/put_user() and small copies can be optimized in the end. > > There is also still hope of optimizing small aligned copies like > > > > set_ttbr0(user_ttbr); > > ldm(); > > set_ttbr0(kernel_ttbr); > > stm(); > > Hmm, more needs to be done to be in a position to test it. This is going to be highly microarchitecture specific, so anything you test on the Beaglebone's Cortex-A8 might not apply to A7/A15/A17 systems, but if you want to test what the overhead is, you could try changing /dev/zero (or a different chardev like it) to use a series of put_user(0, u32uptr++) in place of whatever it has, and then replace the 'str' instruction with dummy writes to ttbr0 using the value it already has, like: mcr p15, 0, %0, c2, c0, 0 /* set_ttbr0() */ isb /* prevent speculative access to kernel table */ str %1, [%2],0 /* write 32 bit to user space */ mcr p15, 0, %0, c2, c0, 0 /* set_ttbr0() */ isb /* prevent speculative access to user table */ This is obviously going to be very slow compared to the simple store there is today but maybe cheaper than the CONFIG_ARM64_SW_TTBR0_PAN uaccess_en/disable() on arm64 on a single get_user()/put_user(). It would be interesting to compare it to the overhead of a get_user_page_fast() based implementation. From the numbers you measured, it seems the beaglebone currently needs an extra ~6=C2=B5s or 3=C2=B5s per copy_to/from_user() call with your patch, depending on what your benchmark was (MB/s for just reading or writing vs MB/s for copying from one file to another through a user space buffer). Arnd