From owner-freebsd-current@freebsd.org Mon Oct 23 20:35:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC8DFE5482D for ; Mon, 23 Oct 2017 20:35:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9079383947 for ; Mon, 23 Oct 2017 20:35:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x231.google.com with SMTP id 17so23631671qkq.8 for ; Mon, 23 Oct 2017 13:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/0TxDEQPa+iGCyUwwF85pXe8XuGkjwfDoXYm2ZUKvfg=; b=AVG5+Ir5azJlpaYvSUAKd2kJQlWWEsfxDQODp6UhR3PGChwqLPQjb4Zr6pACOtFEtH p488Pi0z4a1VTsUdxyvq3LN+kpdR2WljjH9Eo/UM1sRRdPubkDFvd43p3zaupRxr9iTr TcafVfLw0jwXB/Oh1mS5OlA4QtES22Q4GBmSd6V+NWyOehxzmPxJXJx7MzzX8CD17Qys BUbKh/Cca+YtHEgpdrHKhFSy8LPyah+aMDRQlws2R8YxXVPu7sfjiVF56FWMslAjZ/tD s2a848WK9z03M4GJ83OjpB3IHR+bJi06GRbj27qx7h+foIOiR1I69WQfsZ0NpB37e7Ud QpSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/0TxDEQPa+iGCyUwwF85pXe8XuGkjwfDoXYm2ZUKvfg=; b=UOfsreqcbdaBsKVGsdEvUrlMh9qsGPc3s9pFhXpd9do4++MMqVEZrSyDrf33t0Ta14 KqHCoV7QSUVXAfsKz8TYx+cXljFgVgxP3+XuXnE6twlzj5Ktzy2QdBzayp+j47JQo4Aa iH5SvWHmUwOpbmlXcRKhsNl+UXi5R2WZn7vNCS8oYElFU5QSE5fjM5ib9NPUBPI5VjpJ k6ATELbxk9evqmKxHS2EI1e6fqu2Sm7Pcv+IJ55pc6JacomAGUR2ixbezs04E/XgUrRh vJ6ALwllgb8u1zPyEb+fo8tQ8Snm2ztOvAXcrvKM8FYwwzsS0w0AXCJPtgUM1041mB6I OyAg== X-Gm-Message-State: AMCzsaWUYpfsaecIOvEXbsM5897bCVzCQ9FpaLZOYzunIKvGzR03SmLF Wa2WNswoYx/J9PeYBKBe53IS3PsJKYZ9DUIkRbehIQ== X-Google-Smtp-Source: ABhQp+TN6wweX1ZcS9Kd4SPFPmyhbMl9C1J2Q5pMN3/SjZBsYhOgSoYrd5Jf53Xf2AKaM7e/NI2vSYyod/gutOJZShc= X-Received: by 10.55.204.157 with SMTP id n29mr19072117qkl.243.1508790920473; Mon, 23 Oct 2017 13:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.51.167 with HTTP; Mon, 23 Oct 2017 13:35:20 -0700 (PDT) From: Mateusz Guzik Date: Mon, 23 Oct 2017 22:35:20 +0200 Message-ID: Subject: There is *NO* abi stability in -head To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 20:35:21 -0000 This is your friendly reminder that in head struct layouts can change and each update requires you to rebuild *all* modules (including ones which come from ports). In practice you can get away without it most of the time, but if in doubt or seeing funny crashes - *recompile* and test with that. I'm sending this because in upcomming weeks struct thread (and probably more) will start getting fields moved around to improve cache-locality and reduce memory waste Both problems types are well known and rather widespread in big real-world c codebases. 1. memory waste Consider a 64-bit platform with 32-bit ints and 64-bit pointers (coincidently that's e.g. amd64 on *BSD, Linux, Illumos and others): struct crap { int i1; void *p1; int i2; void *p2; }; Normallly fields are aligned to their size. So in particular p1 will be aligned to *8* bytes. But since sizeof i1 is only 4 bytes, there are another 4 bytes straight up wasted. The total sizeo of the obj is 32 bytes. That is, if an object of type struct crap is at address 0x1000, fields will be: 0x1000 i1 0x1008 p1 0x1010 i2 0x1018 p2 Instead, the same can be reshuffled: struct crap2 { int i1; int i2; void *p1; void *p2; }; With offsets: 0x1000 i1 0x1004 i2 0x1008 p1 0x1010 p2 This is only 24 bytes. 2 ints can be placed together and since they add up to 8 the p1 pointer gets the right alignment without extra padding. struct thread accumulated some of this and can just shrink without removing anything. Interested parties can read http://www.catb.org/esr/structure-packing/ 2. cacheline bouncing (profesionnal term: cacheline ping pong) cpus store main memory content in local caches. the smallest unit it reads is 64 bytes (aligned to 64, i.e. reading of 0x1010 will fetch 0x1000). There are fields which are accessed only by the thread owning the struct. If they happen to share the line with something modified by other threads we lose on performance as now the cpu has to talk to some other cpu which has the line modified. This is increasingly painful on numa systems, where response times are longer. Furthermore, if fields frequently read/modified together are very far apart, chances are they require avoidable memory fetches - instead of taking just one line, they may take several. As cache size is finite, this may mean something else useful has to be evicted. For interested parties I can't recommend enough: https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html -- Mateusz Guzik