From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38213 invoked by alias); 10 Nov 2016 08:27:44 -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 38200 invoked by uid 89); 10 Nov 2016 08:27:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=inspection, State X-HELO: mx1.redhat.com Subject: Re: [libc/string] State of PAGE_COPY_FWD / PAGE_COPY_THRESHOLD To: Maxim Kuvyrkov , GNU C Library References: From: Florian Weimer Message-ID: Date: Thu, 10 Nov 2016 08:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00382.txt.bz2 On 11/01/2016 10:28 AM, Maxim Kuvyrkov wrote: > I wanted to check performance impact of using linux zero page sharing in calls to memset (PTR, 0, SIZE). I remembered seeing PAGE_COPY_FWD_MAYBE and PAGE_COPY_THRESHOLD in string/memcpy.c, and my plan was to copy this logic to an experimental memset() implementation. > > Closer inspection of the current code showed that only Mach port attempted to use full-page copying in memcpy.c, but now even the Mach port disables it. The net result is that code in string/memcpy.c, as well as parts of headers sysdeps/generic/pagecopy.h and sysdeps/generic/memcopy.h are dead code. I posted a patch to remove this, but it got stalled. The Mach port no longer compiles on the master branch, so I don't know how we can make changes to it. Florian