From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3783 invoked by alias); 10 Nov 2016 07:52:58 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 3771 invoked by uid 89); 10 Nov 2016 07:52:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=wellknown, well-known, U*pinskia, sk:pinskia X-HELO: mail-wm0-f54.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pHMepWdI3ddufBo7SLW0MGWl8V8RV6qs0WUAwQzUoEA=; b=dLMqlrFBrWCdc2Tix8r4xDQSSkqvY3H44eZ+6TQYmTRYVhBPaY0FbMNAFJrHZ49KVz d//SFm+hhksBwaKcpnJ/3WGDmT+vBlORFfOyH/z1NiAwuncgv99exyRRDLe/3oA7BTQI ZAw2JW5CMa2R+yUf2+0IpVyyVjqdRyUx4+vFqqlpSKof5ImsdmVOjwe8BNBFryVOCzGv p+JYkenI3jI10mmvw4yOZBvKjaARWLF704dopI9rPDWe7pbA6kKdA1fwM5EtoPrrVIwt URJGySEVpr6gjOUU1Eolb0GaFgoapHvLcxIrJiK9xrs/HYjmlx7C+jDzyX9FDYea+ukL 3yOw== X-Gm-Message-State: ABUngvcKME1qanXMCHFoIFA3ao5esXUqHGmPOvcXnTYaYroxL1C5yxCrUMqifX+eD4IjhQ5M X-Received: by 10.194.14.196 with SMTP id r4mr3931089wjc.54.1478764365776; Wed, 09 Nov 2016 23:52:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: [libc/string] State of PAGE_COPY_FWD / PAGE_COPY_THRESHOLD From: Maxim Kuvyrkov In-Reply-To: Date: Thu, 10 Nov 2016 07:52:00 -0000 Cc: Adhemerval Zanella , GNU C Library Content-Transfer-Encoding: quoted-printable Message-Id: References: <193512EC-DC6C-4BDF-8138-1C1F54B30A12@linaro.org> To: Andrew Pinski X-SW-Source: 2016-11/txt/msg00376.txt.bz2 > On Nov 10, 2016, at 11:48 AM, Andrew Pinski wrote: >=20 > On Wed, Nov 9, 2016 at 11:39 PM, Maxim Kuvyrkov > wrote: >>> On Nov 1, 2016, at 5:59 PM, Adhemerval Zanella wrote: >>>=20 >> ... >>> $ cat sysdeps/x86/pagecopy.h >>>=20 >>> #define PAGE_SIZE 4096 >>> #define PAGE_COPY_THRESHOLD PAGE_SIZE >>>=20 >>> #define PAGE_COPY_FWD(dstp, srcp, nbytes_left, nbytes) /* Implement it= */ >>>=20 >>> It should work on any other architecture as well. Now the question >>> is whether this actually does make sense for Linux. Hurd/mach provided >>> a syscall (?) to actually copy the pages (vm_copy) which seems to apply >>> some tricks to avoid full copy pages. By 'linux zero page sharing' are >>> you referring to KSM (Kernel Samepage Merging)? >>>=20 >>> If so, on a system without a provided kernel interface to work directed >>> with underlying memory mapping (such as for mach), mem{cpy,set} will >>> actually need to touch the pages and it will be up to kernel page fault >>> mechanism to actually handle it (by identifying common pages and adjust= ing >>> vma mapping accordingly). And AFAIK this are only enabled on KSM if you >>> actually madavise the page explicit. So I am not grasping the need to >>> actually implement page copying on Linux. >>=20 >> Linux kernel has a reserved page filled with zeroes, so it there /were/ = a syscall to tell kernel to map N consecutive pages starting at address PTR= to that zero page, we could use that in GLIBC for really big memset(0). >>=20 >> A quick investigation shows that there is no such syscall provided by th= e Linux kernel. Doesn't mean we can't ask for / implement one. >=20 > And then there would be a COW interrupt on the first write. Not a > good idea. Since most likely you are writing zeros to a big page for > security reasons before filling it again with other data. I'm looking at this as a possible performance optimization for a well-known= benchmark.=20=20 > That mean > each page would need to be copied which is normally slower than > zeroing in the first place. It may be like you say, or it may be a significant performance improvement.= I want to see numbers before deciding on how useful this may be. >=20 > COW is only useful when most of the pages will not be written to; it > is not useful when doing memcpy or memset. Mainly because you don't > need to take the overhead of taking an interrupt twice (a system call > is still an interrupt). -- Maxim Kuvyrkov www.linaro.org