From owner-svn-src-head@freebsd.org Sat Mar 3 15:17:03 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFCEFF44071 for ; Sat, 3 Mar 2018 15:17:02 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic306-17.consmr.mail.bf2.yahoo.com (sonic306-17.consmr.mail.bf2.yahoo.com [74.6.132.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90EB585825 for ; Sat, 3 Mar 2018 15:17:01 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1520090214; bh=+FTOFOyznmOpmkEeF1WlQHRqWfnUSGawxyl6Cd43aak=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hnsumFpdNmAGpc0aq113iE7GievA+hP2LBRjEcvEFueJjfYcekSI2osm9fdQCrZoqf0+60DTTQfa5KVV8L0j5b3SRQfTKbz4Yc47BoVs8e4w8yKmCeV2i+xx+Ar/59iet1vwpl2XmjzPtO0MAUoEBzOyFyaxn4OIkS/AmX2+FBQVNYH4eAJbAr+PiesozpbVk94JdwrZi4gjv6LhVPdvDc4UBA2WXhpQNe+pwO+/OaIjyGdN54XKSclx48c/16zDy/d9TNh7+Lv354J9lZZZxPNIjxB368k5XCqsseK55H18lhXp0umI//EiLu5sL39U2PtbUhFrEh6Lljtcsv76uA== X-YMail-OSG: yHJ4kFkVM1mrG9PdKSyAW0mU_5yyWh5AqwG235JRY7OuziMgc9ZmU_yTakHqlZu i3xfkx7vc1xWseESE3CYeJLKnvodUBPIO8ItUGVUeuGTNZNYDVIMAPLzyjZ6Y32MCUAlEoLpyFrh 0fCYVLctYM.OYl65L0Al6Ty4KwifkVkVCAGgFgN4ZD0PAnjcESc_IJwqjjGCoeruHmErrE0B1K5w zKo79GxpPRt0GsPoDLT.cAjf8GrPlD2kZm_Cbk8Zb5VJNN3C7mdpZSrkD_EVyQjhOOk1z2fFb6YO Crulw8LP6QiGxjGYxXvi2fPTtNf8W6MJ4kXniZsPGEpd740j5f2.7MpPmPpObIo9uWVZxolx4EAn QFcwtjImzFZ72OiahxyxzsaqLl_LaqUgmFlxsrm7cXyjQxjvKyUxPocdeFebFwMSVhQ3meVKYqCW uIcmzvgO4ZleHUmpghtHzHjeogePHBnxvYhN1xIXbbi8.0cKPduACwP2E1EpZKCUb54A2uekECtW SeLYRqNMj.D4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Sat, 3 Mar 2018 15:16:54 +0000 Received: from 190.157.137.88 (EHLO [192.168.0.5]) ([190.157.137.88]) by smtp423.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID e78e55bf20016dc30f38ca833b477424; Sat, 03 Mar 2018 15:06:44 +0000 (UTC) Subject: Re: svn commit: r330285 - head/sys/sys To: Konstantin Belousov , Bruce Evans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201803021647.w22Gl2t7092316@repo.freebsd.org> <20180302181934.GF3194@kib.kiev.ua> <20180303130511.N1283@besplex.bde.org> <20180303102106.GG3194@kib.kiev.ua> From: Pedro Giffuni Organization: FreeBSD Project Message-ID: <0a205e40-16d3-863a-301c-cc537023ecb9@FreeBSD.org> Date: Sat, 3 Mar 2018 10:06:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180303102106.GG3194@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 15:17:03 -0000 On 03/03/2018 05:21, Konstantin Belousov wrote: > On Sat, Mar 03, 2018 at 01:47:41PM +1100, Bruce Evans wrote: >> On Fri, 2 Mar 2018, Konstantin Belousov wrote: >> >>> On Fri, Mar 02, 2018 at 12:43:34PM -0500, Pedro Giffuni wrote: >>>> ... >>>> I think use of _Nonnull attributes in the threading functions may also >>>> be a waste (I introduced them mostly to be compatible with Android). >>>> FWIW, Dragonfly sprinkled some restrict there recently: >>>> >>>> http://gitweb.dragonflybsd.org/dragonfly.git/commit/d33005aaee6af52c80428b59b52aee522c002492 >>>> >>>> Just in case someone is considering more cleanups. >>> This is not a cleanup for me, but a needed change. Right now x86 >>> copyouts are implemented in asm, so whatever damage is done to the >>> prototypes, only effect is at the caller side. In my work, i386 copyouts >>> are done in C, so it starts matter. >> That seems slow, especially for small sizes as are common for syscall args >> (in 1 of my versions, copyin() of args is optimized to fuword() in a loop, >> and fuword() is optimized to not use pcb_onfault, so it is not much more >> than 1 memory access. However, in your i386 version this optimization >> would be negative since the slow part is switching the map, so fuword() >> should never be used to access multiple words). > Yes. I already explained it in private, the current choice for i386 is > either to be neglected very fast, or to get this change to still be a > Tier 1 32 bit platform. The change is to make 4/4g split for UVA/KVA. > In particular, the change ensures that it is possible to self-host i386 > for forthcoming years, which is not practical for armv7 now and would be > less so with clang grow. > > In other news, my system already boots single-user on SMP machine and > I have torture tests like setting invalid %ss segment by sigreturn(2), > work. There is (much) more to come, but I am happy how the patch > progressed so far. Very nice. >> However, copyinstr() and >> copystr() should never have been "optimized" by writing them in asm. On >> x86, their asm is badly written so they are slower than simple C versions >> except on 8088's and maybe 8086's and maybe on the original i386. (8088's >> were limited mainly by instruction bandwidth and the original i386 wasn't >> much better, so short CISC instructions like lodsb and stosb tended to be >> faster than larger separate instructions despite their large setup overheads. > Sure, copyinstr() is rewritten in C. The current version of copyout stuff > is there: > https://kib.kiev.ua/git/gitweb.cgi?p=deviant2.git;a=blob;f=sys/i386/i386/copyout.c;h=9747c06a84d7d2b5faac946f5de57f6a34d96c8c;hb=refs/heads/pcid > >>> Also I looked at the dragonfly commit because I become curious what do you >>> mean by threading functions. The first example was >>> int pthread_attr_getguardsize(const pthread_attr_t * __restrict, >>> - size_t *); >>> + size_t * __restrict); >>> POSIX agrees with the dragonfly change, but I do not understand it. >>> Aliasing rules already disallow the first and second arguments to point >>> to the same memory, because they have different types. >> (1) thread_attr_t is opaque, so the types might be the same. >> (2) pthread_attr_t might be a pointer to a struct/union containing a size_t. >> (3) perhaps other reasons. I'm not sure how 'restrict interacts with global >> variables or even it it prevents the interaction in (2). A previous >> discussion showed that const doesn't make types different enough to >> prevent aliasing. Similarly for volatile. >> >> Similarly for other pointers to {opaque, struct/union, or even integer} types. >> size_t can't be aliased to int, but it can be aliased to any unsigned type >> in C and to any unsigned type not smaller than uint16_t in POSIX (POSIX >> but not C requires u_char == uint8_t, so size_t can't be u_char in POSIX >> but it can be u_char in C). > I can only summarize it as 'there is no use to have restrict on the > pthread_attr_getguardsize() arguments'. > Well, I'll admit I don't understand well the advantages and that's why I brought up a pointer to the changes instead of working on them. Usually, standards compliance is reason enough for such change though. Pedro.