From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94271 invoked by alias); 10 Nov 2016 07:48:33 -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 94063 invoked by uid 89); 10 Nov 2016 07:48:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=adjusting, tricks, reserved, State X-HELO: mail-yw0-f196.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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NkSXOWBBdxUyAq//3ToH9O95T6UYJn86EcYdhJmumx0=; b=GJqsqYIJ52KBrilSEm96qo94aDScNR7Xmq3M7aJa/2F7oyurcDfTTkGF7frR5TSpCO RM381sSVBk7Ky4ZEaemXlXXPcE8tD2C8PqWTo5J8j19DvcDmi2tt8LlhCY6cB+K2poPk hEhvByUk2DrqTDbyNYD1Xqm4Q34Vs+Ybdt/L/rI15lOrqCR4EyFL17yTf2KZc9YBidqh jc+GrxoHf2DRFDablf5AD7PMTfmzNqhT2rdV55xqo2ak1n7t7PsWCy40ETUPQAwCFrwg 958sYsH1DJNbKoIrN0uqvXPNYr675AE5dINJ9+VDz4aCCj3u+66XTzkbWLXBkmCqB3YN d8AA== X-Gm-Message-State: ABUngvdHSH9QrzWe5WfmMfh/ushNHcptRZe1APiyKB6aN+DZgq7UW38D79MuKHsDRdVOh5WdtWIb6kgqrK2ikg== X-Received: by 10.129.6.146 with SMTP id 140mr3398827ywg.291.1478764095024; Wed, 09 Nov 2016 23:48:15 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <193512EC-DC6C-4BDF-8138-1C1F54B30A12@linaro.org> References: <193512EC-DC6C-4BDF-8138-1C1F54B30A12@linaro.org> From: Andrew Pinski Date: Thu, 10 Nov 2016 07:48:00 -0000 Message-ID: Subject: Re: [libc/string] State of PAGE_COPY_FWD / PAGE_COPY_THRESHOLD To: Maxim Kuvyrkov Cc: Adhemerval Zanella , GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-11/txt/msg00375.txt.bz2 On Wed, Nov 9, 2016 at 11:39 PM, Maxim Kuvyrkov wrote: >> On Nov 1, 2016, at 5:59 PM, Adhemerval Zanella wrote: >> > ... >> $ cat sysdeps/x86/pagecopy.h >> >> #define PAGE_SIZE 4096 >> #define PAGE_COPY_THRESHOLD PAGE_SIZE >> >> #define PAGE_COPY_FWD(dstp, srcp, nbytes_left, nbytes) /* Implement it */ >> >> 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)? >> >> 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 adjusting >> 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. > > 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). > > A quick investigation shows that there is no such syscall provided by the Linux kernel. Doesn't mean we can't ask for / implement one. 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. That mean each page would need to be copied which is normally slower than zeroing in the first place. 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). Thanks, Andrew > > -- > Maxim Kuvyrkov > www.linaro.org > >