From owner-freebsd-arch@FreeBSD.ORG Sun Mar 8 01:35:28 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EFBBED1 for ; Sun, 8 Mar 2015 01:35:28 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 470FD173 for ; Sun, 8 Mar 2015 01:35:28 +0000 (UTC) Received: by igal13 with SMTP id l13so12948284iga.0 for ; Sat, 07 Mar 2015 17:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=4WS7kRLTaZqrmDty51iDHo9ubtl4TiFDxXH9g+OtYHA=; b=ajghhv8HTRXFfyoP+RZF8OPucv7aY/x7zXuvz4/9SAVm4LqjtaNYLdcuI6C/+YIWOH WbM4Ob1Fv1FyWi4upbaDo6jMACbpgUmAtn0mZCJyc0I5hsb0/3FpoKTWd7u9hwBmbFhU DAlrjn10RYxon1mGlc3pAcBPd8oxFShVpzG0yi1trAdM+/p/hzmeMEkUx4uT4wJMFC83 H3zi0+pWvMY8IYDSbjbhcIrMQ5XVCZj4C5zU7jT9q6+C/gVHMavaiA/K9zM03GnCPy9P L0uASKnSTksFY+I1ojc2niMlmG8FePZWJ3v3fXhOtbzJCHsKw9ytRbCOaYED6xdDInAZ PrYA== MIME-Version: 1.0 X-Received: by 10.107.5.211 with SMTP id 202mr4193117iof.88.1425778527599; Sat, 07 Mar 2015 17:35:27 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.66 with HTTP; Sat, 7 Mar 2015 17:35:27 -0800 (PST) Date: Sat, 7 Mar 2015 17:35:27 -0800 X-Google-Sender-Auth: hE0wTSuwU_Oq3tYeQg2PdYFh6GA Message-ID: Subject: A quick dumpster dive through the busdma allocation path.. From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 01:35:28 -0000 Hi, On a lark, I spent today doing a NUMA dumpster dive through the busdma allocation path. The intent was to tag a dmat with a NUMA domain early on (say in pci), so devices would inherit a domain tag when they created tags, and busdma allocations could occur from that domain. here's how it looks so far, dirty as it is: * I've grabbed the vm phys first touch allocator stuff from -9, and shoehorned it into -head; * I've added iterators to the vm_phys code, so there's some concept of configurable policies; * and there's an iterator init function that can take a specific domain, rather than PCPU_GET(domain). That works enough for first-touch and round-robin userland page allocation. it'd be easy to extend it so each proc/thread had a NUMA allocation policy, but I haven't done that. I've done memory bandwidth / math benchmarks and abused pcm.x to check if the allocations are working and indeed the first-touch allocator is doing what is expected. But, I'm much more interested in device allocation in the kernel for ${WORK}. So I wanted to give that a whirl and see what the minimum amount of work to support that is. * the vm_phys routines now have _domain() versions that take a domain id, or -1 for "system/thread default"; * the kmem_alloc routines now have _domain() versions that take a domain id, or -1; * malloc() has a domain() version that takes a domain id or -1; * busdma for x86 has a 'domain' tag that I'm populating as part of PCI, based on bus_get_domain(). That's just a total hack, but hey, it worked enough for testing; I've plumbed the domain id down through uma enough for large page allocation, and that all worked fine. However, I hit a roadblock here: t5nex0: alloc_ring: numa domain: 1; alloc len: 65536 bounce_bus_dmamem_alloc: dmat domain: 1 bounce_bus_dmamem_alloc: kmem_alloc_contig_domain vm_page_alloc_contig_domain: called; domain=1 .. so that's okay. then vm_page_alloc_contig_domain() calls vm_reserv_alloc_contig(), and that's returning an existing region. So vm_page_alloc_contig_domain() never gets to call vm_phys_alloc_contig_domain() to get the physical memory itself. That's where I'm stuck. Right now it seems that since there's no domain awareness in the vm_reserv code, it's just returning an existing region on whatever domain that particular region came from. So, I'm done with the dive for now. It looks like the VM reservation code may need to learn about the existence of domains? Or would it be cleaner/possible to have multiple kmem_object / kernel_object's, one per domain? Thanks, -adrian From owner-freebsd-arch@FreeBSD.ORG Sun Mar 8 22:28:09 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10212AB0 for ; Sun, 8 Mar 2015 22:28:09 +0000 (UTC) Received: from mail.as41113.net (mail.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id B7967F76 for ; Sun, 8 Mar 2015 22:28:07 +0000 (UTC) Received: from [172.21.88.60] (cpc6-staf8-2-0-cust519.3-1.cable.virginm.net [82.16.54.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@m.jwh.me.uk) by mail.as41113.net (Postfix) with ESMTPSA id 3l0cYd3bMNz1N1yB for ; Sun, 8 Mar 2015 22:19:49 +0000 (GMT) Message-ID: <54FCCAEE.7000908@m.jwh.me.uk> Date: Sun, 08 Mar 2015 22:19:26 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: RFC: Simplfying hyperthreading distinctions References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> <2092193.qt8NhEKglv@ralph.baldwin.cx> <54FAC83F.7020008@freebsd.org> In-Reply-To: <54FAC83F.7020008@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 22:28:09 -0000 On 07/03/2015 09:43, Julian Elischer wrote: > On 3/6/15 3:41 PM, John Baldwin wrote: >> We are now in the odd situation where we refer to a small (and >> shrinking) set of CPUs that support HTT as HTT and we refer to a much >> larger (and growing) set of CPUs that support HTT as something else. >> This means that if a random user wants to see if FreeBSD supports HTT >> they won't see that in dmesg on a modern CPU without having some sort >> of magic decoder ring. > I like the HTT (SMT variant) idea. More information is better. Surely the solution here is having an MI term, or perhaps at least one per arch (x86, mips, et al), rather than having one per arch and then per cpu family? Especially given that it is only older CPUs that use HTT rather than SMT then it makes sense to support the majority rather than the minority... (Whilst I have only limited knowledge on the subject it seems like common sense, sorry) From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 12:16:51 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E389355 for ; Wed, 11 Mar 2015 12:16:51 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2954184 for ; Wed, 11 Mar 2015 12:16:50 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 96E891FE022; Wed, 11 Mar 2015 13:16:41 +0100 (CET) Message-ID: <55003258.7010601@selasky.org> Date: Wed, 11 Mar 2015 13:17:28 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "freebsd-arch@freebsd.org" , Marshall Kirk McKusick Subject: Giving names to "new" locking techniques Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 12:16:51 -0000 Hi, What I'm writing here might become topic for a presentation educating other kernel developers at the next EuroBSDcon, so be warned ;-) Some of you familiar to farming knows what happens when you try to kill a chicken using a simple axe. It runs around for a long time after the head is off. This picture can also be used to explain what happens when trying to stop a process in the kernel which is using many different APIs. I think it would be benificial to all developers if new code techniques and solutions to classic locking problems could have a name, that can later be referred and explained, so that we don't go around and stumble and re-invent the wheel when writing [new] code. I attended a talk by Kirk McMusic some years ago where he explained how turnstiles and the internals of the locking system in FreeBSD worked. And I couldn't agree more. Many other people listening did not fully understand what he said. I think there is a strong need to educate people on how to properly use locks and mutexes inside the FreeBSD kernel and not only how locks work internally. I've recently been doing some work in the callout area and I would recommend other developers reading the "AVOIDING RACE CONDITIONS" section in "man 9 timeout" and making up your mind about the three no-name techniques described there. I think it would be fair to force everyone to avoid races using a any kind of exclusivly locked mutex, which is described as "alternative 1" in "man 9 callout". Further I would like the "AVOIDING RACE CONDITIONS" techniques in the callout subsystem to be the good example for everyone else. The USB stack already does similarly to the callout subsystem and it works excellent. And I would like the tools to be available in the kernel to do this easily, like an any-lock API similar to the existing locking classes in 11-current. While at it I would like to collect some terms and words related to locking: - Sleep/non sleepable lock (credits: ???) - Shared/exclusive lock (credits: ???) - Locking order reversal, LOR (credits: ???) - Lock inversion (credits: des@ ???) - Locking whole pieces of code and not only single variables or structures (credits: hselasky@ ???) - Applying locks before calling a function and not inside a function (credits: hselasky@ ???) - Any-locking API. A set of kernel functions that accepts any type of mutex: mtx / SPIN / RM / RW / SX which can be used by API providers to call callback functions locked (credits: ???) Thanks for reading through! Any comments? --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 17:24:02 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8FFE436 for ; Wed, 11 Mar 2015 17:24:02 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (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 716B6E8B for ; Wed, 11 Mar 2015 17:24:02 +0000 (UTC) Received: by iecsl2 with SMTP id sl2so26980iec.1 for ; Wed, 11 Mar 2015 10:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=f7ESP680Q4gelcGh/EK+yXDyLuARK+3rzStqU3InMFY=; b=TpPDHWW255ypYQqhBTr803XT1NN6shSkN7LwV1l+m38DRMs4rrp9WiY2BXEOOhM/Em NNllqmF2vQGoYgpKWKA8fsLSNgSALoTfJs7BNsj+avRqCgCVYdQASThWrB/HGssu3tgu SsFSvx+Mvgji8NWi0XUbmiMlCuSdwWi67nw5ds/Z6v58UaU/HvSGb7nefkcLEpoLn1Rm fh9llwojyenRPdsdFdJLMF3LosKSYZtXXfTj78ddZi5S48nyKJrfZfsGFx8TicyOQQrz +7agFIfzge4xtOBFhmOYDjNy/bwGOP7b1gx/5G6qJ5bBiipFOXNpZN7MGWPgGqq4rzob DPXw== MIME-Version: 1.0 X-Received: by 10.50.66.170 with SMTP id g10mr92972897igt.49.1426094641882; Wed, 11 Mar 2015 10:24:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 11 Mar 2015 10:24:01 -0700 (PDT) Date: Wed, 11 Mar 2015 10:24:01 -0700 X-Google-Sender-Auth: 2icC6gujeusRD4nNCNaq8mmYxaQ Message-ID: Subject: re-visiting the NUMA physical allocator work in -HEAD From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 17:24:02 -0000 hi, I've started fleshing out the vm_phys allocator work in -HEAD. This is based on what's in -9 with some discussions from others - namely, we'd like policies and iterators, rather than just hard-coded stuff. So, here's where i'm doing it: https://github.com/freebsd/freebsd/compare/master...erikarn:local/adrian_numa_policy My aim is to get the following done: * add vm_phys default allocator policies - round robin, first touch, first touch + round robin (done); * convert the vm_phys domain iteration to use an iterator instead of hard-coded stuff (done); * add some basic policy description objects and API - likely just something that's copied around to begin with; * add counters for allocations - by domain; looking at allocation types and whether they were met (ie, things like "domain-local allocation to domain 0 success, domain-local allocation to domain 0 failure; domain 0 round-robin allocation, etc." * add some very basic domain and domain policy awareness to busdma. At this point I'll stop and get buy-in for pushing it into -HEAD. Trying to plumb things through contigmalloc / kmem_alloc / malloc all the way down to vm_phys for domain aware kernel allocations won't happen this pass - the vm_reserv code needs to know about domains and some basic domain policy. I want to get the above done and pushed into -HEAD so we can then build upon it, and that includes teaching vm_reserv about domains and domain policies. I'm treating all of this NUMA stuff as "if it's in -HEAD then great, but the API will be subject to change." With the basic iterator stuff and policy stuff done, I can already measure the effectiveness of first-touch on my dual and quad socket test boxes. It's indeed doing the right thing for some userland use cases. It seems completely silly to not have this bare minimum functionality in -HEAD. :( -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 18:26:14 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F09F4358 for ; Wed, 11 Mar 2015 18:26:14 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8604859 for ; Wed, 11 Mar 2015 18:26:14 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id DD67E104DB9; Wed, 11 Mar 2015 11:26:12 -0700 (PDT) Date: Wed, 11 Mar 2015 11:26:12 -0700 From: hiren panchasara To: "Simon J. Gerraty" Subject: Re: Buggy sbspace() on 64bit builds? Message-ID: <20150311182612.GL88380@strugglingcoder.info> References: <20150206183036.S1246@besplex.bde.org> <5977.1423271024@chaos> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ck22u5fw4m2k6hx2" Content-Disposition: inline In-Reply-To: <5977.1423271024@chaos> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Anuranjan Shukla , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:26:15 -0000 --Ck22u5fw4m2k6hx2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02/06/15 at 05:03P, Simon J. Gerraty wrote: > Anuranjan Shukla wrote: > > this, along with return value being 'int' acceptable as a final > > determination?=20 >=20 > It is ok for the function to return long,=20 > so long as an int is used internally. > Casting the int to long - implicit on return does no harm. >=20 > #include > #include > #include >=20 > int > main(int argc, char *argv[]) > { > uint a, b; > long r1; > int r2; >=20 > a =3D 1; > b =3D 2; >=20 > r1 =3D a - b; > r2 =3D a - b; >=20 > printf("r1=3D%ld\nr2=3D%d\nr3=3D%ld\n", r1, r2, (long)r2); > exit(0); > } >=20 > r1=3D4294967295 > r2=3D-1 > r3=3D-1 >=20 > so I think just using 'int' internally should work for now, > perhaps with a comment saying the object size should match > those being subtracted etc. Hi Simon/Anu, Has this been committed yet? I believe I am running into something similar in our stable10 build. I am not certain though. In any case, this should be committed/mfc'd. Cheers, Hiren --Ck22u5fw4m2k6hx2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVAIjEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l9tUH/3/4B5XRumcFM28t70LIb/27 lnNEU+Xy9ZDfTbZ2J/JNNGgwgJ9jk3rMS3G5vtfKgdSZcCsqxMsJtfiG3Z1Mu9Tn +n/baWWG5JeZzArFHuzR9Svly1sJD/EAm3K+UL1dTWjgFMpgYnstHAeTeMqlW3jb jhKh458zhztZMwQWOQGgUrEnhz9eYmObVF1rr48VFmVX3BE2oaw76SwwtBweE+Ti E1UVxvlsQrSHV+QoutHCEx/f0bh1QnuBL7Ps6m8h4prrJrA073rXG+Rp9JTmACEr Y5ionOdjPmrRWJqxnou1wCsn8WT1D7aHqszqOa17ifXZJK4mo+Syae04huu88Yw= =dj1p -----END PGP SIGNATURE----- --Ck22u5fw4m2k6hx2-- From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 18:39:54 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3AF5A76 for ; Wed, 11 Mar 2015 18:39:54 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB4E89AD for ; Wed, 11 Mar 2015 18:39:54 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id C0601104F46; Wed, 11 Mar 2015 11:39:47 -0700 (PDT) Date: Wed, 11 Mar 2015 11:39:47 -0700 From: hiren panchasara To: Anuranjan Shukla Subject: Re: Buggy sbspace() on 64bit builds? Message-ID: <20150311183947.GM88380@strugglingcoder.info> References: <20150206183036.S1246@besplex.bde.org> <5977.1423271024@chaos> <20150311182612.GL88380@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gQt10JDuGyDb0HQ5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-arch@freebsd.org" , Simon Gerraty X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:39:54 -0000 --gQt10JDuGyDb0HQ5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 03/11/15 at 06:29P, Anuranjan Shukla wrote: > Hi Hiren, > It's been committed to HEAD, r278729. Thanks Anu. I think it should also be MFC'd. Simon, do you mind? :-) Cheers, Hiren --gQt10JDuGyDb0HQ5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVAIvyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lyAwIAKc6Vzbn6tDFs5P/K8JQM6Ev 3pC8PTKuolbED0B6a//ObqwCJN5NpWnXdKPQ7jHlVo7cscez3A8zyptfEaoeuFni pl0UYtgKLhM/zwYMt58e7/6kMQyQjMkaht9eQwC0/wz2Cf24ArXWCWGdqMmYu6PG PAVRWWVzSiVjIoRKnvH63nYm038s1lNW7DFcSVOFy2vlrsGGuoe1wJb0Uttb7/fC RUSy1RotBHP5+iK2mrViaqeliPMAX02xsnbGIOsBJQCsAJ3BEdvN5mgnYIx44+ob 1Jcvf82l9REOeHujbsLBexMO16+OZVjiNpMrmp1FQsIrUPkMLbYF0h9i0ijuZSs= =sRB5 -----END PGP SIGNATURE----- --gQt10JDuGyDb0HQ5-- From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 18:44:08 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69D49C51 for ; Wed, 11 Mar 2015 18:44:08 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0102.outbound.protection.outlook.com [157.56.111.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F13C3A82 for ; Wed, 11 Mar 2015 18:44:07 +0000 (UTC) Received: from BLUPR0501MB1060.namprd05.prod.outlook.com (25.160.36.150) by BY1PR0501MB1542.namprd05.prod.outlook.com (25.160.203.140) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 11 Mar 2015 18:29:41 +0000 Received: from BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) by BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) with mapi id 15.01.0099.004; Wed, 11 Mar 2015 18:29:40 +0000 From: Anuranjan Shukla To: hiren panchasara , Simon Gerraty Subject: Re: Buggy sbspace() on 64bit builds? Thread-Topic: Buggy sbspace() on 64bit builds? Thread-Index: AQHQQa9oYD6vE33IJEufQkyrNnicWZzjUieAgABadwCAALPZAIAzbd4A//+LoIA= Date: Wed, 11 Mar 2015 18:29:39 +0000 Message-ID: References: <20150206183036.S1246@besplex.bde.org> <5977.1423271024@chaos> <20150311182612.GL88380@strugglingcoder.info> In-Reply-To: <20150311182612.GL88380@strugglingcoder.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [66.129.241.12] authentication-results: strugglingcoder.info; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1542; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(51704005)(77156002)(122556002)(62966003)(2950100001)(92566002)(83506001)(87936001)(19580405001)(19580395003)(102836002)(46102003)(76176999)(2900100001)(54356999)(40100003)(50986999)(86362001)(106116001)(99286002)(93886004)(2656002)(36756003)(66066001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1542; H:BLUPR0501MB1060.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY1PR0501MB1542; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1542; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 18:29:39.9615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1542 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:44:08 -0000 Hi Hiren, It's been committed to HEAD, r278729. Thanks. On 3/11/15, 11:26 AM, "hiren panchasara" wrote: >On 02/06/15 at 05:03P, Simon J. Gerraty wrote: >> Anuranjan Shukla wrote: >> > this, along with return value being 'int' acceptable as a final >> > determination? >>=20 >> It is ok for the function to return long, >> so long as an int is used internally. >> Casting the int to long - implicit on return does no harm. >>=20 >> #include >> #include >> #include >>=20 >> int >> main(int argc, char *argv[]) >> { >> uint a, b; >> long r1; >> int r2; >>=20 >> a =3D 1; >> b =3D 2; >>=20 >> r1 =3D a - b; >> r2 =3D a - b; >>=20 >> printf("r1=3D%ld\nr2=3D%d\nr3=3D%ld\n", r1, r2, (long)r2); >> exit(0); >> } >>=20 >> r1=3D4294967295 >> r2=3D-1 >> r3=3D-1 >>=20 >> so I think just using 'int' internally should work for now, >> perhaps with a comment saying the object size should match >> those being subtracted etc. > >Hi Simon/Anu, > >Has this been committed yet? I believe I am running into something >similar in our stable10 build. I am not certain though. In any case, >this should be committed/mfc'd. > >Cheers, >Hiren From owner-freebsd-arch@FreeBSD.ORG Thu Mar 12 15:07:13 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFA5AEFC; Thu, 12 Mar 2015 15:07:12 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACFCF75C; Thu, 12 Mar 2015 15:07:12 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5311B1FE023; Thu, 12 Mar 2015 16:07:09 +0100 (CET) Message-ID: <5501ABCA.7020203@selasky.org> Date: Thu, 12 Mar 2015 16:07:54 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Adding new media types to if_media.h References: <20150226230031.GN17947@glebius.int.ru> <20150227192310.GR17947@glebius.int.ru> <1919032.aFEK3un8ig@ralph.baldwin.cx> In-Reply-To: <1919032.aFEK3un8ig@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , mike@karels.net, "freebsd-net@freebsd.org" , Gleb Smirnoff , Jack Vogel , Eric Joyner X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:07:13 -0000 On 02/28/15 13:28, John Baldwin wrote: > On Friday, February 27, 2015 10:23:10 PM Gleb Smirnoff wrote: >> On Thu, Feb 26, 2015 at 08:25:59PM -0800, Adrian Chadd wrote: >> A> [snip] >> A> >> A> I think Mike's approach is good - it makes it easy to MFC to 10.2 >> A> since there's extended lifecycle stuff to do there - and then we can >> A> plan out how do the "betterer" fix after it's landed and churned >> A> things. >> >> ... and we will be ought to support the "betterer" fix along with >> the "not so betterer" for a very long time. >> >> The rock on which we split in this argument is that some developers >> write their code for stable/x and then forward-port it to head, >> focused on quality of result for stable/x; while other developers >> do the opposite: write code to head, then consider or not consider >> merging it stable/x. > > No, this is not quite true. Some folks have to write drivers on HEAD but also > support running those drivers on older branches. The MFC's get harder when > you have very different APIs on the different branches. It's already harder > to test stat changes now since it requires completely different patches for > <= 10 (the only thing people are supposed to use in production) vs head due to > if_getcounter() and friends. Also, since 11 won't be out until 2016, that is > far, far too long to wait for more media types. The stuff we need to support > is already shipping in products today. We can't not support these in 10 (and > possibly 9). > Any news on this issue? Is anyone working on a solution for -head ? --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Mar 12 16:59:47 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 408E686D; Thu, 12 Mar 2015 16:59:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 164398E0; Thu, 12 Mar 2015 16:59:47 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4B8F3B963; Thu, 12 Mar 2015 12:59:45 -0400 (EDT) From: John Baldwin To: Hans Petter Selasky Subject: Re: Adding new media types to if_media.h Date: Thu, 12 Mar 2015 12:01:13 -0400 Message-ID: <1740987.7L4GidWlzm@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <5501ABCA.7020203@selasky.org> References: <20150226230031.GN17947@glebius.int.ru> <1919032.aFEK3un8ig@ralph.baldwin.cx> <5501ABCA.7020203@selasky.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Mar 2015 12:59:45 -0400 (EDT) Cc: Adrian Chadd , mike@karels.net, "freebsd-net@freebsd.org" , Gleb Smirnoff , Jack Vogel , freebsd-arch@freebsd.org, Eric Joyner X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:59:47 -0000 On Thursday, March 12, 2015 04:07:54 PM Hans Petter Selasky wrote: > On 02/28/15 13:28, John Baldwin wrote: > > On Friday, February 27, 2015 10:23:10 PM Gleb Smirnoff wrote: > >> On Thu, Feb 26, 2015 at 08:25:59PM -0800, Adrian Chadd wrote: > >> A> [snip] > >> A> > >> A> I think Mike's approach is good - it makes it easy to MFC to 10.2 > >> A> since there's extended lifecycle stuff to do there - and then we can > >> A> plan out how do the "betterer" fix after it's landed and churned > >> A> things. > >> > >> ... and we will be ought to support the "betterer" fix along with > >> the "not so betterer" for a very long time. > >> > >> The rock on which we split in this argument is that some developers > >> write their code for stable/x and then forward-port it to head, > >> focused on quality of result for stable/x; while other developers > >> do the opposite: write code to head, then consider or not consider > >> merging it stable/x. > > > > No, this is not quite true. Some folks have to write drivers on HEAD but also > > support running those drivers on older branches. The MFC's get harder when > > you have very different APIs on the different branches. It's already harder > > to test stat changes now since it requires completely different patches for > > <= 10 (the only thing people are supposed to use in production) vs head due to > > if_getcounter() and friends. Also, since 11 won't be out until 2016, that is > > far, far too long to wait for more media types. The stuff we need to support > > is already shipping in products today. We can't not support these in 10 (and > > possibly 9). > > > > Any news on this issue? Is anyone working on a solution for -head ? I believe a variant of Mike's patch is in phabricator now? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Mar 12 17:40:19 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B2FADB4; Thu, 12 Mar 2015 17:40:19 +0000 (UTC) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id BF7DBDBA; Thu, 12 Mar 2015 17:40:18 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.7/8.14.7) with ESMTP id t2CHS2ZM008948; Thu, 12 Mar 2015 12:28:02 -0500 (CDT) (envelope-from mike@karels.net) Message-Id: <201503121728.t2CHS2ZM008948@mail.karels.net> To: John Baldwin From: Mike Karels Reply-to: mike@karels.net Subject: Re: Adding new media types to if_media.h In-reply-to: Your message of Thu, 12 Mar 2015 12:01:13 -0400. <1740987.7L4GidWlzm@ralph.baldwin.cx> Date: Thu, 12 Mar 2015 12:28:02 -0500 Cc: Hans Petter Selasky , Adrian Chadd , "freebsd-net@freebsd.org" , Gleb Smirnoff , Jack Vogel , freebsd-arch@freebsd.org, Eric Joyner X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:40:19 -0000 > > Any news on this issue? Is anyone working on a solution for -head ? > I believe a variant of Mike's patch is in phabricator now? My patch, plus addition of new 10/40 Gb types, is in review D1965. There is an althernative approach in D2008. There hasn't been much activity on either. Take a look! Mike From owner-freebsd-arch@FreeBSD.ORG Thu Mar 12 19:26:45 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBC05D30; Thu, 12 Mar 2015 19:26:45 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A080D0B; Thu, 12 Mar 2015 19:26:45 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3F82B1FE023; Thu, 12 Mar 2015 20:26:42 +0100 (CET) Message-ID: <5501E89F.3050900@selasky.org> Date: Thu, 12 Mar 2015 20:27:27 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mike@karels.net, John Baldwin Subject: Re: Adding new media types to if_media.h References: <201503121728.t2CHS2ZM008948@mail.karels.net> In-Reply-To: <201503121728.t2CHS2ZM008948@mail.karels.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Joyner , "freebsd-net@freebsd.org" , Adrian Chadd , Jack Vogel , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 19:26:46 -0000 On 03/12/15 18:28, Mike Karels wrote: >>> Any news on this issue? Is anyone working on a solution for -head ? > >> I believe a variant of Mike's patch is in phabricator now? > > My patch, plus addition of new 10/40 Gb types, is in review D1965. > There is an althernative approach in D2008. There hasn't been much > activity on either. Take a look! > Hi, I've just uploaded another less intrusive suggestion, including 100GBase types needed by coming Mellanox hardware. https://reviews.freebsd.org/D2056 Feel free to comment. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Mar 12 20:10:38 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6889BDEB for ; Thu, 12 Mar 2015 20:10:38 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0116.outbound.protection.outlook.com [157.56.111.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 082C027B for ; Thu, 12 Mar 2015 20:10:37 +0000 (UTC) Received: from BLUPR05CA0057.namprd05.prod.outlook.com (10.141.20.27) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.99.14; Thu, 12 Mar 2015 19:35:40 +0000 Received: from BY2FFO11FD025.protection.gbl (2a01:111:f400:7c0c::160) by BLUPR05CA0057.outlook.office365.com (2a01:111:e400:855::27) with Microsoft SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Thu, 12 Mar 2015 19:35:40 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Thu, 12 Mar 2015 19:35:39 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Mar 2015 12:35:39 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t2CJZcD39717; Thu, 12 Mar 2015 12:35:38 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 035ED580A3; Thu, 12 Mar 2015 12:35:38 -0700 (PDT) To: hiren panchasara Subject: Re: Buggy sbspace() on 64bit builds? In-Reply-To: <20150311183947.GM88380@strugglingcoder.info> References: <20150206183036.S1246@besplex.bde.org> <5977.1423271024@chaos> <20150311182612.GL88380@strugglingcoder.info> <20150311183947.GM88380@strugglingcoder.info> Comments: In-reply-to: hiren panchasara message dated "Wed, 11 Mar 2015 11:39:47 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 12 Mar 2015 12:35:37 -0700 Message-ID: <22443.1426188937@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=sjg@juniper.net; freebsd.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(92566002)(86362001)(50466002)(6806004)(2950100001)(76506005)(48376002)(47776003)(57986006)(87936001)(558084003)(117636001)(77156002)(76176999)(105596002)(93886004)(77096005)(62966003)(50986999)(50226001)(46102003)(110136001)(33716001)(106466001)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001009)(5005006); SRVR:BN1PR05MB440; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB440; X-Forefront-PRVS: 05134F8B4F X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2015 19:35:39.8981 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[P-EMF03-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Cc: Anuranjan Shukla , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 20:10:38 -0000 This is done r279930 > > It's been committed to HEAD, r278729. > > Thanks Anu. I think it should also be MFC'd. > > Simon, do you mind? :-) > > Cheers, > Hiren From owner-freebsd-arch@FreeBSD.ORG Fri Mar 13 18:31:09 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CCE9EF3; Fri, 13 Mar 2015 18:31:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13E0DA0; Fri, 13 Mar 2015 18:31:09 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ACE4BB93B; Fri, 13 Mar 2015 14:31:07 -0400 (EDT) From: John Baldwin To: Nathan Whitehorn Subject: Re: RFC: Simplfying hyperthreading distinctions Date: Fri, 13 Mar 2015 13:58:37 -0400 Message-ID: <2058936.CdnVTM8mMb@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54FA5EE9.4090305@freebsd.org> References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> <54FA5EE9.4090305@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Mar 2015 14:31:07 -0400 (EDT) Cc: 'Andriy Gapon' , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 18:31:09 -0000 On Friday, March 06, 2015 06:14:01 PM Nathan Whitehorn wrote: > > On 03/06/15 12:44, John Baldwin wrote: > > Currently we go out of our way a bit to distinguish Pentium4-era > > hyperthreading from more recent ("modern") hyperthreading. I suspect that > > this distinction probably results in confusion more than anything else. > > Intel's documentation does not make near as broad a distinction as far as I > > can tell. Both types of SMT are called hyperthreading in the SDM for example. > > However, we have the astonishing behavior that > > 'machdep.hyperthreading_allowed' only affects "old" hyperthreads, but not > > "new" ones. We also try to be overly cute in our dmesg output by using HTT > > for "old" hyperthreading, and SMT for "new" hyperthreading. I propose the > > following changes to simplify things a bit: > > > > 1) Call both "old" and "new" hyperthreading HTT in dmesg. > > > > 2) Change machdep.hyperthreading_allowed to apply to both new and old HTT. > > However, doing this means a POLA violation in that we would now disable > > modern HTT by default. Balanced against re-enabling "old" HTT by default > > on an increasingly-shrinking pool of old hardware, I think the better > > approach here would be to also change the default to allow HTT. > > > > 3) Possibly add a different knob (or change the behavior of > > machdep.hyperthreading_allowed) to still bring up hyperthreads, but leave > > them out of the default cpuset (set 1). This would allow those threads > > to be re-enabled dynamically at runtime by adjusting the mask on set 1. > > The original htt settings back when 'hyperthreading_allowed' was > > introduced actually permitted this via by adjusting 'machdep.hlt_cpus' at > > runtime. > > > > What do people think? > > I'm fine with whatever naming, but if we're making new sysctls, > especially for the cpuset case, is there a reason to hide the behavior > under machdep? We support at least three non-x86 CPUs with SMT (POWER8, > Cell, and POWER5) and the relevant scheduling logic should be MI. At > least POWER8 supports 8 threads per core, so you might also want more > granularity than just "on" or "off". 3) would involve something new, yes, but my immediate concern is more 1) and 2) to make x86 more consistent. I would certainly be fine with having an MI name for 3). When I've prototyped it before I did it in an MD SYSINIT, but I can perhaps make use of the topology flags to do this in MI code instead. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Mar 13 18:31:09 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F9AAEF6; Fri, 13 Mar 2015 18:31:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66C1FA1; Fri, 13 Mar 2015 18:31:09 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 59A2DB945; Fri, 13 Mar 2015 14:31:08 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: RFC: Simplfying hyperthreading distinctions Date: Fri, 13 Mar 2015 13:53:40 -0400 Message-ID: <2652866.1YVC5LhOC2@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <1640664.8z9mx3EOQs@ralph.baldwin.cx> <2092193.qt8NhEKglv@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Mar 2015 14:31:08 -0400 (EDT) Cc: Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 18:31:09 -0000 On Friday, March 06, 2015 03:45:13 PM Adrian Chadd wrote: > Hi! > > Hm, I looked at this: > > https://en.wikipedia.org/wiki/Bonnell_%28microarchitecture%29 > > .. and thought it was old-school HTT. If it's not old-school HTT then cool. It is not. The SDM manuals explicitly differentiate Atom CPUs from Pentium 4 when talking about HTT (oddly they don't really mention Core-based CPUs I believe because new HTT first showed up in Atoms and they never bothered to update that part of the SDM?). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Mar 13 23:16:14 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3582D74; Fri, 13 Mar 2015 23:16:14 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 2D7C375E; Fri, 13 Mar 2015 23:16:14 +0000 (UTC) Received: by wiwl15 with SMTP id l15so827685wiw.1; Fri, 13 Mar 2015 16:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=X6U98Pj1Ppstv0C7R4uECUDYz3qORZkSUSCfmRwLXRQ=; b=oVekECIV9z3rx/l94eFV2I1995nRH4ZseDOkEedi8+HzY3cVnc9SIjW2zvioYrlfZu YJGDIc7l/kvGxWWkP5DIYQD4CTA1eAXFwNyjnOXGQmv2TM4Asn4neTOSQG+rcO+/o/vH yHbSop4hTxu3n8cqtEGWEF3GRvgxeNKVjmohLrR1esay25/stJU9bBCFlZRiJeDCXx1h lKowmVBDu3V5KlVfdf7JOBSiuN74YdynEX1urFIDWgG7/0UAqrFM3KVbOgIghILx5axR AqXgTSgoTArXc1Xuz5lPFm9+uBr++lkQlE2QM1bhi/kbw19QzqBIIM3TBIa3eW7Nm6XP sG9Q== X-Received: by 10.180.106.103 with SMTP id gt7mr145089650wib.59.1426288572332; Fri, 13 Mar 2015 16:16:12 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id at4sm4711922wjc.16.2015.03.13.16.16.09 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 16:16:10 -0700 (PDT) Date: Sat, 14 Mar 2015 00:16:07 +0100 From: Mateusz Guzik To: John Baldwin Subject: Re: refcount_release_take_##lock Message-ID: <20150313231607.GB32157@dft-labs.eu> References: <20141025184448.GA19066@dft-labs.eu> <201410281413.58414.jhb@freebsd.org> <20141028193404.GB12014@dft-labs.eu> <201411111427.15407.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201411111427.15407.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: John-Mark Gurney , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 23:16:14 -0000 In the meantime I wrote a new version. Apart from locking-handling primitives this time we get refcount_acquire_if_greater and refcount_release_if_greater helpers. This diff contains an example usage for kern_resource.c which will be committed separately. diff --git a/share/man/man9/refcount.9 b/share/man/man9/refcount.9 index b3c8d7f..1b66a9d 100644 --- a/share/man/man9/refcount.9 +++ b/share/man/man9/refcount.9 @@ -26,14 +26,20 @@ .\" .\" $FreeBSD$ .\" -.Dd January 20, 2009 +.Dd March 13, 2015 .Dt REFCOUNT 9 .Os .Sh NAME .Nm refcount , .Nm refcount_init , .Nm refcount_acquire , -.Nm refcount_release +.Nm refcount_release , +.Nm refcount_acquire_if_greater , +.Nm refcount_release_if_greater , +.Nm refcount_release_lock_mtx , +.Nm refcount_release_lock_rmlock , +.Nm refcount_release_lock_rwlock , +.Nm refcount_release_lock_sx .Nd manage a simple reference counter .Sh SYNOPSIS .In sys/param.h @@ -44,6 +50,22 @@ .Fn refcount_acquire "volatile u_int *count" .Ft int .Fn refcount_release "volatile u_int *count" +.Ft int +.Fn refcount_acquire_if_greater "volatile u_int *count" "u_int value" +.Ft int +.Fn refcount_release_if_greater "volatile u_int *count" "u_int value" +.In sys/lock.h + +.In sys/mutex.h +.Ft int +.Fn refcount_release_lock_mtx "volatile u_int *count, struct mtx *lock" +.In sys/rmlock.h +.Ft int +.Fn refcount_release_lock_rmlock "volatile u_int *count, struct rmlock *lock" +.In sys/rwlock.h +.Fn refcount_release_lock_rwlock "volatile u_int *count, struct rwlock *lock" +.In sys/sx.h +.Fn refcount_release_lock_sx "volatile u_int *count, struct sx *lock" .Sh DESCRIPTION The .Nm @@ -77,6 +99,52 @@ The function returns a non-zero value if the reference being released was the last reference; otherwise, it returns zero. .Pp +The +.Fn refcount_acquire_if_greater +function works like +.Fn refcount_acquire +with the exception that the counter value has to be +greater than the one provided as an argument. +.Pp +The +.Fn refcount_release_if_greater +function works like +.Fn refcount_release +with the exception that the counter value has to be +greater than the one provided as an argument. +.Pp +The +.Fn refcount_release_lock_mtx +function is used to atomically release an existing reference and acquire the +lock. +The function returns with the lock held and a non-zero value if the reference +being released was the last reference; +otherwise, it returns zero and the lock is not held. +.Pp +The +.Fn refcount_release_lock_rmlock +function is used to atomically release an existing reference and acquire the +lock. +The function returns with the lock held and a non-zero value if the reference +being released was the last reference; +otherwise, it returns zero and the lock is not held. +.Pp +The +.Fn refcount_release_lock_rwlock +function is used to atomically release an existing reference and acquire the +lock. +The function returns with the lock held and a non-zero value if the reference +being released was the last reference; +otherwise, it returns zero and the lock is not held. +.Pp +The +.Fn refcount_release_lock_sx +function is used to atomically release an existing reference and acquire the +lock. +The function returns with the lock held and a non-zero value if the reference +being released was the last reference; +otherwise, it returns zero and the lock is not held. +.Pp Note that these routines do not provide any inter-CPU synchronization, data protection, or memory ordering guarantees except for managing the counter. @@ -91,6 +159,42 @@ The .Nm refcount_release function returns non-zero when releasing the last reference and zero when releasing any other reference. +.Pp +The +.Nm refcount_acquire_if_greater +function returns non-zero if the reference was acquired and zero otherwise. +.Pp +The +.Nm refcount_release_if_greater +function returns non-zero if the reference was released and zero otherwise. +.Pp +The +.Nm refcount_release_lock_mtx +function returns non-zero if the reference was released and zero otherwise. +.Pp +The +.Nm refcount_release_lock_rmlock +function returns non-zero if the reference was released and zero otherwise. +.Pp +The +.Nm refcount_release_lock_rwlock +function returns non-zero if the reference was released and zero otherwise. +.Pp +The +.Nm refcount_release_lock_sx +function returns non-zero if the reference was released and zero otherwise. .Sh HISTORY -These functions were introduced in +.Fn refcount_acquire +and +.Fn refcount_release +functions were introduced in .Fx 6.0 . +.Pp +.Fn refcount_acquire_if_greater , +.Fn refcount_release_if_greater , +.Fn refcount_release_lock_mtx , +.Fn refcount_release_lock_rmlock , +.Fn refcount_release_lock_rwlock , +.Fn refcount_release_lock_sx +functions were introduced in +.Fx 11 . diff --git a/sys/kern/kern_resource.c b/sys/kern/kern_resource.c index 56b598f..6489538 100644 --- a/sys/kern/kern_resource.c +++ b/sys/kern/kern_resource.c @@ -1303,20 +1303,10 @@ uihold(struct uidinfo *uip) void uifree(struct uidinfo *uip) { - int old; - /* Prepare for optimal case. */ - old = uip->ui_ref; - if (old > 1 && atomic_cmpset_int(&uip->ui_ref, old, old - 1)) + if (!refcount_release_lock_rwlock(&uip->ui_ref, &uihashtbl_lock)) return; - /* Prepare for suboptimal case. */ - rw_wlock(&uihashtbl_lock); - if (refcount_release(&uip->ui_ref) == 0) { - rw_wunlock(&uihashtbl_lock); - return; - } - racct_destroy(&uip->ui_racct); LIST_REMOVE(uip, ui_hash); rw_wunlock(&uihashtbl_lock); diff --git a/sys/sys/refcount.h b/sys/sys/refcount.h index 4611664..b6ddb90 100644 --- a/sys/sys/refcount.h +++ b/sys/sys/refcount.h @@ -64,4 +64,64 @@ refcount_release(volatile u_int *count) return (old == 1); } +static __inline int +refcount_acquire_if_greater(volatile u_int *count, int val) +{ + int old; + + for (;;) { + old = *count; + if (old <= val) + return (0); + if (atomic_cmpset_int(count, old, old + 1)) + return (1); + } +} + +static __inline int +refcount_release_if_greater(volatile u_int *count, int val) +{ + int old; + + for (;;) { + old = *count; + if (old <= val) + return (0); + if (atomic_cmpset_int(count, old, old - 1)) + return (1); + } +} + +#define _refcount_release_lock(count, lock, TYPE, LOCK_OP, UNLOCK_OP) \ +({ \ + TYPE *__lock; \ + volatile u_int *__cp; \ + int __ret; \ + \ + __lock = (lock); \ + __cp = (count); \ + \ + if (refcount_release_if_greater(__cp, 1)) { \ + __ret = 0; \ + } else { \ + LOCK_OP(__lock); \ + if (refcount_release(__cp)) { \ + __ret = 1; \ + } else { \ + UNLOCK_OP(__lock); \ + __ret = 0; \ + } \ + } \ + __ret; \ +}) + +#define refcount_release_lock_mtx(count, lock) \ + _refcount_release_lock(count, lock, struct mtx, mtx_lock, mtx_unlock) +#define refcount_release_lock_rmlock(count, lock) \ + _refcount_release_lock(count, lock, struct rmlock, rm_wlock, rm_wunlock) +#define refcount_release_lock_rwlock(count, lock) \ + _refcount_release_lock(count, lock, struct rwlock, rw_wlock, rw_wunlock) +#define refcount_release_lock_sx(count, lock) \ + _refcount_release_lock(count, lock, struct sx, sx_xlock, sx_xunlock) + #endif /* ! __SYS_REFCOUNT_H__ */ -- Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Fri Mar 13 23:58:39 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6A008B5; Fri, 13 Mar 2015 23:58:39 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7697FAF3; Fri, 13 Mar 2015 23:58:39 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t2DNwcjx077069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 16:58:38 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t2DNwchf077068; Fri, 13 Mar 2015 16:58:38 -0700 (PDT) (envelope-from jmg) Date: Fri, 13 Mar 2015 16:58:38 -0700 From: John-Mark Gurney To: Mateusz Guzik Subject: Re: refcount_release_take_##lock Message-ID: <20150313235838.GM32288@funkthat.com> References: <20141025184448.GA19066@dft-labs.eu> <201410281413.58414.jhb@freebsd.org> <20141028193404.GB12014@dft-labs.eu> <201411111427.15407.jhb@freebsd.org> <20150313231607.GB32157@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150313231607.GB32157@dft-labs.eu> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 13 Mar 2015 16:58:38 -0700 (PDT) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 23:58:39 -0000 Mateusz Guzik wrote this message on Sat, Mar 14, 2015 at 00:16 +0100: > In the meantime I wrote a new version. > > Apart from locking-handling primitives this time we get > refcount_acquire_if_greater and refcount_release_if_greater helpers. I don't see how this is of any benefit... The smallest value you can provide is 0, which means the only time a reference can be obtained is if the caller already has a reference. If you don't have a reference (making it =0), it isn't safe to call this function on the object, as it could be free'd, and point to a different type of object... Even if you implement type-safe memory (which we shouldn't use more of), it's less than ideal, since you then have to check if the object is the same object you were expecting, and need to release it... The release_if is even more problematic IMO... After reading the previous discussion, I really don't like this. If this gets approved (others override my objection), we need some docs that say this should never be used, and it's use is only in the unsafe case where the containing data structure does NOT have a reference to the object. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sat Mar 14 00:15:32 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9DE1CF9; Sat, 14 Mar 2015 00:15:31 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (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 668A9CDF; Sat, 14 Mar 2015 00:15:31 +0000 (UTC) Received: by webcq43 with SMTP id cq43so2618431web.2; Fri, 13 Mar 2015 17:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=8vJSl0ejEwo197LUGo/c8l5cr6TVHx4WCnYJONbAl8s=; b=hXxpRjPM3KsrMBDYHc3MUa69uSEvzUsbu0BxqnQeRgJzNDAlJX0+aNGqDagzZbbxMG Wy4u/7T9/lj1DVnzRLWsTLI6aJ9h3ZMes1NodJmnh6NQee31hZQ7/hOP2+8VGL7U0OT3 UyTVyjhxD5Gn87MDR1DHywL0u1sklSAUFC+S/z1qOXPD20iQbOzenbKhV9+Cut97OrKD 2l1zUiSwLh3Vi/dbpgSzpS4T3vtHeOVr0MI2/eyu1bPBim8OL0p/MiAau43tbkxK6HTJ pLgfL245u3KNJYY20QLG2E+V/ZlX4eV5uYooDmSL0zmIrnrvMsrjz+czP2PRf+I3kHf7 PLEg== X-Received: by 10.180.105.40 with SMTP id gj8mr147563248wib.67.1426292129783; Fri, 13 Mar 2015 17:15:29 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id n6sm4868661wjy.8.2015.03.13.17.15.28 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 17:15:28 -0700 (PDT) Date: Sat, 14 Mar 2015 01:15:26 +0100 From: Mateusz Guzik To: John-Mark Gurney Subject: Re: refcount_release_take_##lock Message-ID: <20150314001526.GC32157@dft-labs.eu> References: <20141025184448.GA19066@dft-labs.eu> <201410281413.58414.jhb@freebsd.org> <20141028193404.GB12014@dft-labs.eu> <201411111427.15407.jhb@freebsd.org> <20150313231607.GB32157@dft-labs.eu> <20150313235838.GM32288@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150313235838.GM32288@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 00:15:32 -0000 On Fri, Mar 13, 2015 at 04:58:38PM -0700, John-Mark Gurney wrote: > Mateusz Guzik wrote this message on Sat, Mar 14, 2015 at 00:16 +0100: > > In the meantime I wrote a new version. > > > > Apart from locking-handling primitives this time we get > > refcount_acquire_if_greater and refcount_release_if_greater helpers. > > I don't see how this is of any benefit... The smallest value you can > provide is 0, which means the only time a reference can be obtained is > if the caller already has a reference. If you don't have a reference > (making it =0), it isn't safe to call this function on the object, as > it could be free'd, and point to a different type of object... Even if > you implement type-safe memory (which we shouldn't use more of), it's > less than ideal, since you then have to check if the object is the same > object you were expecting, and need to release it... > > The release_if is even more problematic IMO... > I see I forgot to note the rationale in my e-mail. The kernel already uses 'refing an object with ref = 0' extensively in vfs. For instance entering a name to the namecache does not increase hold count of the vnode. A thread doing lookup locks the cache shared, locks the interlock, unlocks the cache and calls vget which blindly vholds the vnode, which quite often does transition 0->1. What prevents freeing of the vnode is name cache lock and later the interlock. All v_holdcnt manipulation is done with the interlock held. Crucial value changes are 0->1 and 1->0 and we need the lock here to ensure consistency. However, as long as we modify this counter in a way which does not go 0->1 nor 1->0 we don't have take the interlock and not doing so increases scalability. So for instance in aforementioned case of namecache, the vnode is kept stable by namecache lock and if v_holdcnt is >=1, we can increase it without taking the interlock which I plan to do. But in order to do that I need primitives which wrap such functionality. Once more, stability of the object in question has to be ensured in other manners. > After reading the previous discussion, I really don't like this. If > this gets approved (others override my objection), we need some docs > that say this should never be used, and it's use is only in the unsafe > case where the containing data structure does NOT have a reference to > the object. Well it should be quite obvious you can't just ref random objects. :> -- Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Sat Mar 14 00:49:24 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CF5E2B2; Sat, 14 Mar 2015 00:49:24 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (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 0339BF61; Sat, 14 Mar 2015 00:49:24 +0000 (UTC) Received: by wegp1 with SMTP id p1so2895155weg.1; Fri, 13 Mar 2015 17:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Rb88us7MY+gscrWDR+boGIDDfqK2dlcjoKMeAex1E+E=; b=dKD0sIbIhI1JOR5aI5YdOpXVKJ5+fo2bU+DH7Wxt7qpkgZcG1RzIeL8mfIFfZ2XYAD 3bvc5M/whAozrm0mtSdwLA48NH3pBoJxeVNqETFnLslHeJulcDB/46fQeOQ7tOt18R41 UZMzb8Oqk4U+Rk1+W2Q/XROcouL/+IoC37AKZMc5L8KZL5nColSGvsISodmP67AXR+kh ejOAuN0PM5mzTsNCcb8N4w77SULy3UyhLyvKiVj0L7sQqwKDfPGIsyZmGFun8PvqBe67 59JoB18bPL6sRrJh5TGxZLbJr5L1nuSBHpsq1ahdpXVMrt0wwWtQqSdHUvpiTdizLWA1 RMuA== X-Received: by 10.180.9.134 with SMTP id z6mr23789686wia.81.1426294162095; Fri, 13 Mar 2015 17:49:22 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id vq9sm4947429wjc.6.2015.03.13.17.49.20 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 17:49:21 -0700 (PDT) Date: Sat, 14 Mar 2015 01:49:17 +0100 From: Mateusz Guzik To: John-Mark Gurney Subject: Re: refcount_release_take_##lock Message-ID: <20150314004917.GD32157@dft-labs.eu> References: <20141025184448.GA19066@dft-labs.eu> <201410281413.58414.jhb@freebsd.org> <20141028193404.GB12014@dft-labs.eu> <201411111427.15407.jhb@freebsd.org> <20150313231607.GB32157@dft-labs.eu> <20150313235838.GM32288@funkthat.com> <20150314001526.GC32157@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150314001526.GC32157@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 00:49:24 -0000 On Sat, Mar 14, 2015 at 01:15:26AM +0100, Mateusz Guzik wrote: > On Fri, Mar 13, 2015 at 04:58:38PM -0700, John-Mark Gurney wrote: > > Mateusz Guzik wrote this message on Sat, Mar 14, 2015 at 00:16 +0100: > > > In the meantime I wrote a new version. > > > > > > Apart from locking-handling primitives this time we get > > > refcount_acquire_if_greater and refcount_release_if_greater helpers. > > > > I don't see how this is of any benefit... The smallest value you can > > provide is 0, which means the only time a reference can be obtained is > > if the caller already has a reference. If you don't have a reference > > (making it =0), it isn't safe to call this function on the object, as > > it could be free'd, and point to a different type of object... Even if > > you implement type-safe memory (which we shouldn't use more of), it's > > less than ideal, since you then have to check if the object is the same > > object you were expecting, and need to release it... > > > > The release_if is even more problematic IMO... > > > > I see I forgot to note the rationale in my e-mail. > > The kernel already uses 'refing an object with ref = 0' extensively in > vfs. > > For instance entering a name to the namecache does not increase hold > count of the vnode. > > A thread doing lookup locks the cache shared, locks the interlock, > unlocks the cache and calls vget which blindly vholds the vnode, > which quite often does transition 0->1. > > What prevents freeing of the vnode is name cache lock and later the > interlock. > > All v_holdcnt manipulation is done with the interlock held. Crucial > value changes are 0->1 and 1->0 and we need the lock here to ensure > consistency. > > However, as long as we modify this counter in a way which does not go > 0->1 nor 1->0 we don't have take the interlock and not doing so increases > scalability. > > So for instance in aforementioned case of namecache, the vnode is kept > stable by namecache lock and if v_holdcnt is >=1, we can increase it > without taking the interlock which I plan to do. > > But in order to do that I need primitives which wrap such functionality. > > Once more, stability of the object in question has to be ensured in > other manners. > > > After reading the previous discussion, I really don't like this. If > > this gets approved (others override my objection), we need some docs > > that say this should never be used, and it's use is only in the unsafe > > case where the containing data structure does NOT have a reference to > > the object. > > Well it should be quite obvious you can't just ref random objects. :> > One of the things i don't like is the fact that we don't have a refcount_t. If we did, we could do the following: with debug enabled it would be extended with a function pointer. On init you would: refcount_init(&refc, asserting_func); So that if you use 0->1 transition, you can provide a function which asserts that appropriate locks are held if you happen to trigger such a case. I doubt there is any runtime relible way to check that you could ref in general. Would this help with your concerns? In genearl, I don't see how you can go around 0->1 transitions in some cases without introducing a bunch of ugly code which only increases complexity. If you are so concerned that *_if functions can encourage refcount mismanage, we can put a big fat warning no problem. -- Mateusz Guzik