From owner-freebsd-arch@freebsd.org Tue Jul 14 22:00:52 2015 Return-Path: Delivered-To: freebsd-arch@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 E534E9A1C8A for ; Tue, 14 Jul 2015 22:00:51 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 BF44210C8 for ; Tue, 14 Jul 2015 22:00:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4F141B9C3; Tue, 14 Jul 2015 18:00:50 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Jason Harmening Subject: Re: RFC: New KPI for fast temporary single-page KVA mappings Date: Tue, 14 Jul 2015 11:30:23 -0700 Message-ID: <6021359.Zicubn765k@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: 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); Tue, 14 Jul 2015 18:00:50 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 22:00:52 -0000 On Tuesday, July 07, 2015 11:37:55 AM Jason Harmening wrote: > Hi everyone, > > I'd like to propose a couple of new pmap functions: > vm_offset_t pmap_quick_enter_page(vm_page_t m) > void pmap_quick_remove_page(vm_offset_t kva) > > These functions will create and destroy a temporary, usually CPU-local > mapping of the specified page. Where available, they will use the direct > map. Otherwise, they will use a per-CPU pageframe that's allocated at boot. > > Guarantees: > --Will not sleep > --Will not fail > --Safe to call under a non-spin lock or from an ithread > > Restrictions: > --Not safe to call from interrupt filter or under a spin mutex on all arches > --Mappings should be held for as little time as possible; don't do any > locking or sleeping while holding a mapping > --Current implementation only guarantees a single page of mapping space > across all arches. MI code should not make nested calls to > pmap_quick_enter_page(). > > My idea is that the first consumer of this would be busdma. All non-iommu > implementations would use this for bounce buffer copies of pages that don't > have resident mappings. Currently busdma uses physcopy[in|out] for > unmapped buffers, which on most arches uses sf_bufs that can sleep, making > bus_dmamap_sync() unsafe to call in a lot of cases. busdma would also use > this for virtually-indexed cache maintenance on arm and mips. It currently > ignores cache maintenance for buffers that don't have a KVA or resident UVA > mapping, which may not be correct for buffers that don't belong to curproc > or have cache-resident VAs on other cores. > > I've created 2 Differential reviews: > https://reviews.freebsd.org/D3013: the implementation > https://reviews.freebsd.org/D3014: the kmod I've been using to test it > > I'd like any and all feedback, both on the general approach and the > implementation details. Some things to note on the implementation: > --I've intentionally avoided touching existing pmap code for the time > being. Some of the new code could likely be shared with other pmap KPIs in > a lot of cases. > --I've structured the KPI to make it easy to extend to guarantee more than > one per-CPU page in the future. I could see that being useful for copying > between pages, for example > --There's no immediate consumer for the sparc64 implementation, since > busdma there needs neither bounce buffers nor cache maintenance. > --I would very much like feedback and testing from experts on non-x86 > arches. I only have hardware to test the i386 and amd64 implementations; > I've only cross-compiled it for everything else. Some of the non-x86 > details, like the Book E powerpc TLB invalidation code, are a bit scary and > probably not quite right. I do think something like this would be useful. What I had wanted to do was to add a 'memory cursor' to go along with memory descriptors. The idea would be that you can use a cursor to iterate over any descriptor, and that one of the options when creating a virtual address cursor was to ask it to preallocate any resources it needs at creation time (e.g. a page of KVA on platforms without a direct map). Then if a driver or GEOM module needs to walk over arbitrary I/O buffers that come down via virtual addresses, it could allocate one or more cursors. I have a partial implementation of cursors in a p4 branch, but it of course is missing the hard part of VA mappings without a direct map. However, this would let you have N of these things and to also control the lifecycle of the temporary KVA addresses instead of having a fixed set. -- John Baldwin From owner-freebsd-arch@freebsd.org Wed Jul 15 00:20:18 2015 Return-Path: Delivered-To: freebsd-arch@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 A43D399C0A7 for ; Wed, 15 Jul 2015 00:20:18 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 88B5515D7 for ; Wed, 15 Jul 2015 00:20:18 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8535999C0A6; Wed, 15 Jul 2015 00:20:18 +0000 (UTC) Delivered-To: arch@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 83B0299C0A5 for ; Wed, 15 Jul 2015 00:20:18 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) 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 6622C15D5 for ; Wed, 15 Jul 2015 00:20:15 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t6F0KEpQ054244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2015 17:20:14 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t6F0KDri054243; Tue, 14 Jul 2015 17:20:13 -0700 (PDT) (envelope-from jmg) Date: Tue, 14 Jul 2015 17:20:13 -0700 From: John-Mark Gurney To: arch@FreeBSD.org Cc: Poul-Henning Kamp Subject: add inverse option to ministat Message-ID: <20150715002013.GZ8523@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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]); Tue, 14 Jul 2015 17:20:14 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 00:20:18 -0000 I have created a patch to invert the data passed into ministat. It is often easier to measure data in time (seconds) using /usr/bin/time or another method, but often you like to think in per second, or throughput which is the inverse. Instead of having to massage the data, or know that below a certain percentage you can just flip the sign, provide this, and you'll now convert to x per second, giving you an easier comparision for talking. Review: https://reviews.freebsd.org/D3084 Thanks. -- 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 Wed Jul 15 06:49:27 2015 Return-Path: Delivered-To: freebsd-arch@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 BA0969A28EA for ; Wed, 15 Jul 2015 06:49:27 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A506B1116 for ; Wed, 15 Jul 2015 06:49:27 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id A2A599A28E9; Wed, 15 Jul 2015 06:49:27 +0000 (UTC) Delivered-To: arch@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 A14899A28E8 for ; Wed, 15 Jul 2015 06:49:27 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 657241115 for ; Wed, 15 Jul 2015 06:49:27 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id AEECE3BB88; Wed, 15 Jul 2015 06:49:25 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t6F6nOtj077610; Wed, 15 Jul 2015 06:49:24 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney cc: arch@FreeBSD.org Subject: Re: add inverse option to ministat In-reply-to: <20150715002013.GZ8523@funkthat.com> From: "Poul-Henning Kamp" References: <20150715002013.GZ8523@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77608.1436942964.1@critter.freebsd.dk> Date: Wed, 15 Jul 2015 06:49:24 +0000 Message-ID: <77609.1436942964@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 06:49:27 -0000 -------- In message <20150715002013.GZ8523@funkthat.com>, John-Mark Gurney writes: >Instead of having to massage the data, or know that below a certain >percentage you can just flip the sign, provide this, and you'll now >convert to x per second, giving you an easier comparision for talking. Why isn't this fundamentally against the UNIX and Software Tools Philosphy and the first step on a long road to turn ministat into R ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Wed Jul 15 06:59:28 2015 Return-Path: Delivered-To: freebsd-arch@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 40FC89A2ABD for ; Wed, 15 Jul 2015 06:59:28 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6CD199A for ; Wed, 15 Jul 2015 06:59:28 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 29F5E9A2ABC; Wed, 15 Jul 2015 06:59:28 +0000 (UTC) Delivered-To: arch@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 288F09A2ABB for ; Wed, 15 Jul 2015 06:59:28 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 5F3E01997 for ; Wed, 15 Jul 2015 06:59:26 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: (qmail 5652 invoked by uid 89); 15 Jul 2015 06:59:25 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@88.217.180.206) by mail.grem.de with ESMTPA; 15 Jul 2015 06:59:25 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: add inverse option to ministat From: Michael Gmelin X-Mailer: iPhone Mail (12H143) In-Reply-To: <20150715002013.GZ8523@funkthat.com> Date: Wed, 15 Jul 2015 08:59:24 +0200 Cc: "arch@FreeBSD.org" , Poul-Henning Kamp Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150715002013.GZ8523@funkthat.com> To: John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 06:59:28 -0000 > On 15 Jul 2015, at 02:20, John-Mark Gurney wrote: >=20 > I have created a patch to invert the data passed into ministat. It > is often easier to measure data in time (seconds) using /usr/bin/time > or another method, but often you like to think in per second, or > throughput which is the inverse. >=20 > Instead of having to massage the data, or know that below a certain > percentage you can just flip the sign, provide this, and you'll now > convert to x per second, giving you an easier comparision for talking. Are you certain that such a minor patch requires adding "Copyright 2015 Netf= lix, Inc"? >=20 > Review: https://reviews.freebsd.org/D3084 >=20 > Thanks. >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Wed Jul 15 07:15:37 2015 Return-Path: Delivered-To: freebsd-arch@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 3653C9A2D9C for ; Wed, 15 Jul 2015 07:15:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 183201FBE for ; Wed, 15 Jul 2015 07:15:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.ysv.freebsd.org (Postfix) id 17CA09A2D9B; Wed, 15 Jul 2015 07:15:37 +0000 (UTC) Delivered-To: arch@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 175DF9A2D9A for ; Wed, 15 Jul 2015 07:15:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) 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 EAC5E1FBD for ; Wed, 15 Jul 2015 07:15:36 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t6F7FZ9W059111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2015 00:15:35 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t6F7FYBD059110; Wed, 15 Jul 2015 00:15:34 -0700 (PDT) (envelope-from jmg) Date: Wed, 15 Jul 2015 00:15:34 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: add inverse option to ministat Message-ID: <20150715071534.GE8523@funkthat.com> References: <20150715002013.GZ8523@funkthat.com> <77609.1436942964@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77609.1436942964@critter.freebsd.dk> 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]); Wed, 15 Jul 2015 00:15:35 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 07:15:37 -0000 Poul-Henning Kamp wrote this message on Wed, Jul 15, 2015 at 06:49 +0000: > -------- > In message <20150715002013.GZ8523@funkthat.com>, John-Mark Gurney writes: > > >Instead of having to massage the data, or know that below a certain > >percentage you can just flip the sign, provide this, and you'll now > >convert to x per second, giving you an easier comparision for talking. > > Why isn't this fundamentally against the UNIX and Software Tools Philosphy > and the first step on a long road to turn ministat into R ? Didn't that get violated when options -C and -d were added in r161692? -- 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 Wed Jul 15 08:17:47 2015 Return-Path: Delivered-To: freebsd-arch@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 C21909A2AA9 for ; Wed, 15 Jul 2015 08:17:47 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A7EDF166E for ; Wed, 15 Jul 2015 08:17:47 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id A73649A2AA8; Wed, 15 Jul 2015 08:17:47 +0000 (UTC) Delivered-To: arch@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 A6BD79A2AA7 for ; Wed, 15 Jul 2015 08:17:47 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6CCFA166B for ; Wed, 15 Jul 2015 08:17:47 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DD68E3BB88; Wed, 15 Jul 2015 08:17:44 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t6F86UKi078060; Wed, 15 Jul 2015 08:06:31 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney cc: arch@freebsd.org Subject: Re: add inverse option to ministat In-reply-to: <20150715071534.GE8523@funkthat.com> From: "Poul-Henning Kamp" References: <20150715002013.GZ8523@funkthat.com> <77609.1436942964@critter.freebsd.dk> <20150715071534.GE8523@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78058.1436947590.1@critter.freebsd.dk> Date: Wed, 15 Jul 2015 08:06:30 +0000 Message-ID: <78059.1436947590@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 08:17:48 -0000 -------- In message <20150715071534.GE8523@funkthat.com>, John-Mark Gurney writes: >Poul-Henning Kamp wrote this message on Wed, Jul 15, 2015 at 06:49 +0000: >> -------- >> In message <20150715002013.GZ8523@funkthat.com>, John-Mark Gurney writes: >> >> >Instead of having to massage the data, or know that below a certain >> >percentage you can just flip the sign, provide this, and you'll now >> >convert to x per second, giving you an easier comparision for talking. >> >> Why isn't this fundamentally against the UNIX and Software Tools Philosphy >> and the first step on a long road to turn ministat into R ? > >Didn't that get violated when options -C and -d were added in r161692? Those have pretty solid precedents in cut(1), sort(1) etc. I protest primarily because I called it *mini*stat for a reason, and secondarily because I think it is a slippery slope doing it operator by operator the way this patch invites to, next thing you know we will have -a(dd) -s(ubtract) -m(ultiply) and -d(ivide). *Iff* we want to allow transformations of input values, we should be general about it, and allow people to enter a full expression: ministat -e '(x - 645134) / 1203.5 + 7.5' But that means adding another full expression evaluator to the tree because none of the many we already have offer a library interface, and once you've implemented +,-,/,* people will ask for log(), exp() and... The shortcut to just hack it so ministat does a popen(awk) to do the math, doesn't offer anything over running awk by hand in my view. There are of course ways we could do this "right": If we had an official "little-language" in the base-system (Tcl, Lua, Intercal - pick your poison) we could use that, but apart from the religions fundamentalism, little languages always suffer from latent chronic obesity. A more feasible way might be to adopt plan9's pipe-trick, where fopen(3) does popen(3) if the first char is '|': ministat "|awk '{print 1/$1}' file1" "|awk '{print 1/$1}' file2" (I never understood why that got shouted down in 199x, and I still think it would be a damn nice feature to have...) But for ministat specificall, I'd rather stop before we even get started, point at the 'mini' and tell people to run awk(1) or learn R if they need non-mini functionality. PS: I also agree with Michael that claiming copyright for adding a single division operation comes across as a bit expansionist. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Wed Jul 15 14:15:28 2015 Return-Path: Delivered-To: freebsd-arch@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 C3D639A1ED1 for ; Wed, 15 Jul 2015 14:15:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 5F8C71E85; Wed, 15 Jul 2015 14:15:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t6FEFM1Q008082 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Jul 2015 17:15:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t6FEFM1Q008082 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t6FEFMLY008081; Wed, 15 Jul 2015 17:15:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Jul 2015 17:15:22 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-arch@freebsd.org, Jason Harmening Subject: Re: RFC: New KPI for fast temporary single-page KVA mappings Message-ID: <20150715141522.GE2404@kib.kiev.ua> References: <6021359.Zicubn765k@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6021359.Zicubn765k@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 14:15:28 -0000 On Tue, Jul 14, 2015 at 11:30:23AM -0700, John Baldwin wrote: > On Tuesday, July 07, 2015 11:37:55 AM Jason Harmening wrote: > > Hi everyone, > > > > I'd like to propose a couple of new pmap functions: > > vm_offset_t pmap_quick_enter_page(vm_page_t m) > > void pmap_quick_remove_page(vm_offset_t kva) > > > > These functions will create and destroy a temporary, usually CPU-local > > mapping of the specified page. Where available, they will use the direct > > map. Otherwise, they will use a per-CPU pageframe that's allocated at boot. > > > > Guarantees: > > --Will not sleep > > --Will not fail > > --Safe to call under a non-spin lock or from an ithread > > > > Restrictions: > > --Not safe to call from interrupt filter or under a spin mutex on all arches > > --Mappings should be held for as little time as possible; don't do any > > locking or sleeping while holding a mapping > > --Current implementation only guarantees a single page of mapping space > > across all arches. MI code should not make nested calls to > > pmap_quick_enter_page(). > > > > My idea is that the first consumer of this would be busdma. All non-iommu > > implementations would use this for bounce buffer copies of pages that don't > > have resident mappings. Currently busdma uses physcopy[in|out] for > > unmapped buffers, which on most arches uses sf_bufs that can sleep, making > > bus_dmamap_sync() unsafe to call in a lot of cases. busdma would also use > > this for virtually-indexed cache maintenance on arm and mips. It currently > > ignores cache maintenance for buffers that don't have a KVA or resident UVA > > mapping, which may not be correct for buffers that don't belong to curproc > > or have cache-resident VAs on other cores. > > > > I've created 2 Differential reviews: > > https://reviews.freebsd.org/D3013: the implementation > > https://reviews.freebsd.org/D3014: the kmod I've been using to test it > > > > I'd like any and all feedback, both on the general approach and the > > implementation details. Some things to note on the implementation: > > --I've intentionally avoided touching existing pmap code for the time > > being. Some of the new code could likely be shared with other pmap KPIs in > > a lot of cases. > > --I've structured the KPI to make it easy to extend to guarantee more than > > one per-CPU page in the future. I could see that being useful for copying > > between pages, for example > > --There's no immediate consumer for the sparc64 implementation, since > > busdma there needs neither bounce buffers nor cache maintenance. > > --I would very much like feedback and testing from experts on non-x86 > > arches. I only have hardware to test the i386 and amd64 implementations; > > I've only cross-compiled it for everything else. Some of the non-x86 > > details, like the Book E powerpc TLB invalidation code, are a bit scary and > > probably not quite right. > > I do think something like this would be useful. What I had wanted to do was > to add a 'memory cursor' to go along with memory descriptors. The idea would > be that you can use a cursor to iterate over any descriptor, and that one of > the options when creating a virtual address cursor was to ask it to preallocate > any resources it needs at creation time (e.g. a page of KVA on platforms without > a direct map). Then if a driver or GEOM module needs to walk over arbitrary > I/O buffers that come down via virtual addresses, it could allocate one or more > cursors. > > I have a partial implementation of cursors in a p4 branch, but it of course is > missing the hard part of VA mappings without a direct map. However, this would > let you have N of these things and to also control the lifecycle of the temporary > KVA addresses instead of having a fixed set. > I do not quite agree that the proposed KPI and your description of cursors have much in common. >From what I read above, the implementation of the temporal VA mappings for cursors should be easy. You need to allocate VA at the time of cursor initialization, and then do pmap_qenter() when needed. In fact, it would be not trivial for the direct map case, to optimize out unneeded VA allocation and qenter. The proposed KPI has rather different goals, it does not need any pre-setup for use, but still it can be used and guarantees to not fail from the hard contexts, like swi or interrupt threads (in particular, it works in the busdma callback context). My opinion is that the KPI and cursors are for different goals. Might be, the KPI could be used as a building foundation for some cursor' functionality. From owner-freebsd-arch@freebsd.org Wed Jul 15 17:41:41 2015 Return-Path: Delivered-To: freebsd-arch@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 718379A2B2C for ; Wed, 15 Jul 2015 17:41:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 523F31202 for ; Wed, 15 Jul 2015 17:41:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4F6FC9A2B2B; Wed, 15 Jul 2015 17:41:41 +0000 (UTC) Delivered-To: arch@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 4EE6B9A2B2A for ; Wed, 15 Jul 2015 17:41:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) 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 2B1A91200 for ; Wed, 15 Jul 2015 17:41:40 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t6FHfdcA068155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jul 2015 10:41:39 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t6FHfdN1068154; Wed, 15 Jul 2015 10:41:39 -0700 (PDT) (envelope-from jmg) Date: Wed, 15 Jul 2015 10:41:39 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: add inverse option to ministat Message-ID: <20150715174139.GJ8523@funkthat.com> References: <20150715002013.GZ8523@funkthat.com> <77609.1436942964@critter.freebsd.dk> <20150715071534.GE8523@funkthat.com> <78059.1436947590@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78059.1436947590@critter.freebsd.dk> 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]); Wed, 15 Jul 2015 10:41:39 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 17:41:41 -0000 Poul-Henning Kamp wrote this message on Wed, Jul 15, 2015 at 08:06 +0000: > -------- > In message <20150715071534.GE8523@funkthat.com>, John-Mark Gurney writes: > >Poul-Henning Kamp wrote this message on Wed, Jul 15, 2015 at 06:49 +0000: > >> -------- > >> In message <20150715002013.GZ8523@funkthat.com>, John-Mark Gurney writes: > >> > >> >Instead of having to massage the data, or know that below a certain > >> >percentage you can just flip the sign, provide this, and you'll now > >> >convert to x per second, giving you an easier comparision for talking. > >> > >> Why isn't this fundamentally against the UNIX and Software Tools Philosphy > >> and the first step on a long road to turn ministat into R ? > > > >Didn't that get violated when options -C and -d were added in r161692? > > Those have pretty solid precedents in cut(1), sort(1) etc. There are lots of tools the repeat functionality... and it's only getting worse... And the amount of code that this adds is strikingly small... Size before the change: text data bss dec hex filename 17617 804 4448 22869 0x5955 /usr/bin/ministat Size after the change: text data bss dec hex filename 17953 804 4448 23205 0x5aa5 /usr/bin/ministat So, we're talking 336 bytes larger... I am surprised it's that much larger, though I guess I did add usage and a new error message.. > I protest primarily because I called it *mini*stat for a reason, > and secondarily because I think it is a slippery slope doing it > operator by operator the way this patch invites to, next thing you > know we will have -a(dd) -s(ubtract) -m(ultiply) and -d(ivide). Which is partly why I only added this one function... It lets it still be mini, but give you meaningful numbers w/o having to do complicated math afterward (if the differences are large enough to justify the math).. > *Iff* we want to allow transformations of input values, we should be > general about it, and allow people to enter a full expression: > > ministat -e '(x - 645134) / 1203.5 + 7.5' I see less value in this, though that's because I'm more interested in differences of numbers, not the absolute numbers... As you said, R... > But that means adding another full expression evaluator to the tree > because none of the many we already have offer a library interface, > and once you've implemented +,-,/,* people will ask for log(), exp() > and... Agreed... > The shortcut to just hack it so ministat does a popen(awk) to do > the math, doesn't offer anything over running awk by hand in my > view. IMO, it does have a benefit... It allows you to not use temporary files... Though now that I think of it, I guess I could just use awk before writing the files... Though I would loose data, or my awk program would become more complicated... > There are of course ways we could do this "right": > > If we had an official "little-language" in the base-system (Tcl, > Lua, Intercal - pick your poison) we could use that, but apart from > the religions fundamentalism, little languages always suffer from > latent chronic obesity. > > A more feasible way might be to adopt plan9's pipe-trick, where > fopen(3) does popen(3) if the first char is '|': > > ministat "|awk '{print 1/$1}' file1" "|awk '{print 1/$1}' file2" > > (I never understood why that got shouted down in 199x, and I still > think it would be a damn nice feature to have...) We already have this feature in awk.. > But for ministat specificall, I'd rather stop before we even get > started, point at the 'mini' and tell people to run awk(1) or learn > R if they need non-mini functionality. I still think it is a good idea... It's small change, not intrusive.. I've now spent about 5x time discussing this than it took to write the patch in the first place... > PS: I also agree with Michael that claiming copyright for adding a > single division operation comes across as a bit expansionist. As I explained to him, the Copyright is on the man page, not the code... -- 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 Wed Jul 15 20:26:15 2015 Return-Path: Delivered-To: freebsd-arch@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 991CE9A212D for ; Wed, 15 Jul 2015 20:26:15 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 0312B10F7; Wed, 15 Jul 2015 20:26:15 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by lbbpo10 with SMTP id po10so31786357lbb.3; Wed, 15 Jul 2015 13:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iLQU0Nq/0i6NW9km73pLJbaIEg66fmNqS4W/k99N3L4=; b=pIPuDu9UI7KevANzjiyCz/wbiVMweYNL7EUvNnckFfDB8zbmcddOmY4gvy6AjqpIYK Gk1esjUsUVh0gY7OBiuBkw0Fd6xUaPIvxfO5MwY+4jdRcugDpgC/OX4QFyx23/rBLGFP t9ILh4tsEdl1Qe60UoaT3wKcmz5ZhYZSZhObZH3rCOat4Q9TxkQ0UbNVfFJqAdTduhgl 7TYlJH1d8wKPUL2XYrL0AHue+oOOT2ejjflQWeZdJ/Hx6T6Ts9337WJKgjeK0jCZHZxi NcdBqK8depfjPEl7yeLCfXz+qJ+256GhUmw5Lhmw9voxs1mMzvl5OtecrybsSuY9naJ/ gFvg== MIME-Version: 1.0 X-Received: by 10.152.6.1 with SMTP id w1mr5866152law.91.1436991972985; Wed, 15 Jul 2015 13:26:12 -0700 (PDT) Received: by 10.112.42.162 with HTTP; Wed, 15 Jul 2015 13:26:12 -0700 (PDT) In-Reply-To: <20150715141522.GE2404@kib.kiev.ua> References: <6021359.Zicubn765k@ralph.baldwin.cx> <20150715141522.GE2404@kib.kiev.ua> Date: Wed, 15 Jul 2015 15:26:12 -0500 Message-ID: Subject: Re: RFC: New KPI for fast temporary single-page KVA mappings From: Jason Harmening To: Konstantin Belousov Cc: John Baldwin , FreeBSD Arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 20:26:15 -0000 Yeah, I see both this and cursors as being useful for different purposes. Code that just needs to do a simple, quick operation on a page and doesn't want to worry about setup/teardown and synchronization (or needs to work under low-KVA conditions) could use pmap_quick_enter_page(). More complex code, especially code that needs a lot of pages in-flight at the same time, could use cursors. As kib mentioned, kva_alloc() + pmap_qenter() seems like a ready-made MI cursor implementation. If you want to optimize for direct maps, you could make MD cursor implementations that bypass those steps; that's very roughly what physcopy* does. But, I'm not sure if that would be worth the trouble. For the most part, the arches that have comprehensive direct maps are also 64-bit arches where KVA pageframes are the most plentiful. Would it make sense to reimplement sf_bufs as a pool of cursors? On Wed, Jul 15, 2015 at 9:15 AM, Konstantin Belousov wrote: > On Tue, Jul 14, 2015 at 11:30:23AM -0700, John Baldwin wrote: > > On Tuesday, July 07, 2015 11:37:55 AM Jason Harmening wrote: > > > Hi everyone, > > > > > > I'd like to propose a couple of new pmap functions: > > > vm_offset_t pmap_quick_enter_page(vm_page_t m) > > > void pmap_quick_remove_page(vm_offset_t kva) > > > > > > These functions will create and destroy a temporary, usually CPU-local > > > mapping of the specified page. Where available, they will use the > direct > > > map. Otherwise, they will use a per-CPU pageframe that's allocated at > boot. > > > > > > Guarantees: > > > --Will not sleep > > > --Will not fail > > > --Safe to call under a non-spin lock or from an ithread > > > > > > Restrictions: > > > --Not safe to call from interrupt filter or under a spin mutex on all > arches > > > --Mappings should be held for as little time as possible; don't do any > > > locking or sleeping while holding a mapping > > > --Current implementation only guarantees a single page of mapping space > > > across all arches. MI code should not make nested calls to > > > pmap_quick_enter_page(). > > > > > > My idea is that the first consumer of this would be busdma. All > non-iommu > > > implementations would use this for bounce buffer copies of pages that > don't > > > have resident mappings. Currently busdma uses physcopy[in|out] for > > > unmapped buffers, which on most arches uses sf_bufs that can sleep, > making > > > bus_dmamap_sync() unsafe to call in a lot of cases. busdma would also > use > > > this for virtually-indexed cache maintenance on arm and mips. It > currently > > > ignores cache maintenance for buffers that don't have a KVA or > resident UVA > > > mapping, which may not be correct for buffers that don't belong to > curproc > > > or have cache-resident VAs on other cores. > > > > > > I've created 2 Differential reviews: > > > https://reviews.freebsd.org/D3013: the implementation > > > https://reviews.freebsd.org/D3014: the kmod I've been using to test it > > > > > > I'd like any and all feedback, both on the general approach and the > > > implementation details. Some things to note on the implementation: > > > --I've intentionally avoided touching existing pmap code for the time > > > being. Some of the new code could likely be shared with other pmap > KPIs in > > > a lot of cases. > > > --I've structured the KPI to make it easy to extend to guarantee more > than > > > one per-CPU page in the future. I could see that being useful for > copying > > > between pages, for example > > > --There's no immediate consumer for the sparc64 implementation, since > > > busdma there needs neither bounce buffers nor cache maintenance. > > > --I would very much like feedback and testing from experts on non-x86 > > > arches. I only have hardware to test the i386 and amd64 > implementations; > > > I've only cross-compiled it for everything else. Some of the non-x86 > > > details, like the Book E powerpc TLB invalidation code, are a bit > scary and > > > probably not quite right. > > > > I do think something like this would be useful. What I had wanted to do > was > > to add a 'memory cursor' to go along with memory descriptors. The idea > would > > be that you can use a cursor to iterate over any descriptor, and that > one of > > the options when creating a virtual address cursor was to ask it to > preallocate > > any resources it needs at creation time (e.g. a page of KVA on platforms > without > > a direct map). Then if a driver or GEOM module needs to walk over > arbitrary > > I/O buffers that come down via virtual addresses, it could allocate one > or more > > cursors. > > > > I have a partial implementation of cursors in a p4 branch, but it of > course is > > missing the hard part of VA mappings without a direct map. However, > this would > > let you have N of these things and to also control the lifecycle of the > temporary > > KVA addresses instead of having a fixed set. > > > > I do not quite agree that the proposed KPI and your description of cursors > have much in common. > > From what I read above, the implementation of the temporal VA mappings > for cursors should be easy. You need to allocate VA at the time of > cursor initialization, and then do pmap_qenter() when needed. In fact, > it would be not trivial for the direct map case, to optimize out > unneeded VA allocation and qenter. > > The proposed KPI has rather different goals, it does not need any > pre-setup for use, but still it can be used and guarantees to not fail > from the hard contexts, like swi or interrupt threads (in particular, it > works in the busdma callback context). > > My opinion is that the KPI and cursors are for different goals. Might > be, the KPI could be used as a building foundation for some cursor' > functionality. > From owner-freebsd-arch@freebsd.org Wed Jul 15 20:31:03 2015 Return-Path: Delivered-To: freebsd-arch@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 05B099A2302 for ; Wed, 15 Jul 2015 20:31:03 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E3AB51525 for ; Wed, 15 Jul 2015 20:31:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id E289A9A2301; Wed, 15 Jul 2015 20:31:02 +0000 (UTC) Delivered-To: arch@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 E130B9A2300 for ; Wed, 15 Jul 2015 20:31:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A824B151F for ; Wed, 15 Jul 2015 20:31:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id EBD8E3BD35; Wed, 15 Jul 2015 20:30:54 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t6FKUrAH080034; Wed, 15 Jul 2015 20:30:54 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney cc: arch@freebsd.org Subject: Re: add inverse option to ministat In-reply-to: <20150715174139.GJ8523@funkthat.com> From: "Poul-Henning Kamp" References: <20150715002013.GZ8523@funkthat.com> <77609.1436942964@critter.freebsd.dk> <20150715071534.GE8523@funkthat.com> <78059.1436947590@critter.freebsd.dk> <20150715174139.GJ8523@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80032.1436992253.1@critter.freebsd.dk> Date: Wed, 15 Jul 2015 20:30:53 +0000 Message-ID: <80033.1436992253@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 20:31:03 -0000 -------- In message <20150715174139.GJ8523@funkthat.com>, John-Mark Gurney writes: >There are lots of tools the repeat functionality... and it's only >getting worse... And the amount of code that this adds is strikingly >small... We do agree that is not a coherent argument, right ? I still think it is a step in the wrong direction, and that it should therefore not be taken. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu Jul 16 02:38:54 2015 Return-Path: Delivered-To: freebsd-arch@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 0655F9A3C62 for ; Thu, 16 Jul 2015 02:38:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D2EA81ADC for ; Thu, 16 Jul 2015 02:38:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id D1DC89A3C61; Thu, 16 Jul 2015 02:38:53 +0000 (UTC) Delivered-To: arch@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 B78EA9A3C60 for ; Thu, 16 Jul 2015 02:38:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 84BB11ADB for ; Thu, 16 Jul 2015 02:38:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by iebmu5 with SMTP id mu5so46811846ieb.1 for ; Wed, 15 Jul 2015 19:38:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=dglL4WQEZ2VwPuYZ6ehBOWbToz1fpE0SgCIQ3U5rQw0=; b=dOfhssF4xWtOjwwvuXIEWLvBhpi3jRGocPTwOZ/o5/AqdCOSQs8IddeDPKxDRV2iuW CJBuqQVl46qtT4VVrFs+BaFkrBzn6rEtofk/+L4YVyv69NUQ+MECp8+CXnW0vr1aJVXu 3O4ViCs0z8AKpdXpTDsUmaEb4P0BFBKMr8avvV/vwmR0OIss9mTpk3C58nNIMokJdec3 iJvSPAwnZbz9VfhO1UU9F5+bdxfBRTKRMpk8kUjCKjKDbF8VkvLui7aLeoRn6MflTpvx Gkt/YVjKpbh3eMTUUJZCaKjd0nUtCXuo4Iksy9+bizgplZF0BQ/EVjt5ErM3SiMBSSW3 sC4w== X-Gm-Message-State: ALoCoQnIP1Wi/yNXLNx6Zbab4D/tFiwrPTc3MQTVa4C89bXjpBa5usoAak3VlTehE4gp4W7HuFlp X-Received: by 10.107.163.16 with SMTP id m16mr7886587ioe.31.1437013851975; Wed, 15 Jul 2015 19:30:51 -0700 (PDT) Received: from [10.0.27.94] ([96.88.71.26]) by smtp.gmail.com with ESMTPSA id s5sm446868igh.6.2015.07.15.19.30.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jul 2015 19:30:51 -0700 (PDT) Sender: Warner Losh Subject: Re: add inverse option to ministat Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0690CF42-3866-4D99-88FD-E78BA1D4EF01"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Warner Losh In-Reply-To: <80033.1436992253@critter.freebsd.dk> Date: Wed, 15 Jul 2015 20:30:50 -0600 Cc: John-Mark Gurney , arch@freebsd.org Message-Id: <10B832D6-08CB-4D4A-910D-75808CDE6549@bsdimp.com> References: <20150715002013.GZ8523@funkthat.com> <77609.1436942964@critter.freebsd.dk> <20150715071534.GE8523@funkthat.com> <78059.1436947590@critter.freebsd.dk> <20150715174139.GJ8523@funkthat.com> <80033.1436992253@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.2102) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 02:38:54 -0000 --Apple-Mail=_0690CF42-3866-4D99-88FD-E78BA1D4EF01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 15, 2015, at 2:30 PM, Poul-Henning Kamp = wrote: >=20 > -------- > In message <20150715174139.GJ8523@funkthat.com>, John-Mark Gurney = writes: >=20 >> There are lots of tools the repeat functionality... and it's only >> getting worse... And the amount of code that this adds is strikingly >> small... >=20 > We do agree that is not a coherent argument, right ? >=20 > I still think it is a step in the wrong direction, and that it should > therefore not be taken. I agree that this is a step best not taken. This is ministat, and why = are we optimizing for this one use-case, when there=E2=80=99s dozens of = other that I=E2=80=99ve wished for over the years. What=E2=80=99s next -l for = log(x) and -e for exp(x)? But if reason doesn=E2=80=99t prevail, can we at least name it right? = The current name isn=E2=80=99t quite appropriate. You=E2=80=99re transitioning from time = domain to the frequency domain, and just saying that it=E2=80=99s inverse. Warner --Apple-Mail=_0690CF42-3866-4D99-88FD-E78BA1D4EF01 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVpxdaAAoJEGwc0Sh9sBEALMAQAMfFvY5GXbb0Czn/0TWVW/pd ZV/oC/VrJjd8PAu7IYvDBjgbAwlmmbf/Djnq87D2TgdIyE78KTPSnZ2OFCYpjp0s DVI0K4ujult9cx1rTF8T7oV0y4hbLMZNC8XjflehuetS9QNicd/0pxVFjRh+f6e1 GsIjJNJ/r5qU21DSDCGiQUlkK6qe3VK0sp5hrWLQR80Jqlcn/77Ky03+Sl4mGpJ8 dEOO+sPxwLjRKIWQedesqGg5XkPDIgvw+9KknrHm/3QlBIV3aWTh+Ol0V0+CHLTE JCcm7qZHXm39fJq72JR6bKFfNrFi4R3oQVXyQ4U6i1YzRnVnzqY1LeXVl6t6VarL kktNCIzK0z7IVlc0UFdtPI2l2vvvY7Ky+6/dRntZjL3aOshsujtU9SssOpORMdVE 1IkCiMUKgU8Kpyn0gKay+UeWFsLHU56+GTym0Wx/hWc8G7PTEgPsB2c/0Z2lVSaO +DgkFqV2PCKEI8wTcf5FjaGfG+Rcf0APQtNp7H/yXiRqCVceiul4v2Ueoo4tZq70 uDGhy1VfrxQj8sWn0pVKsKmxfm3GT6ltcyOmLetq7j7NRhkGWw5qYazzEi5ytth0 mQscIlQ4EyHhDyOFcLqkMxB0Pf4POoDOaPJJollzMgx9DC/3dHyhV4LZoAVUacgP hQvtmNWVpDvx/9IEp31r =ynER -----END PGP SIGNATURE----- --Apple-Mail=_0690CF42-3866-4D99-88FD-E78BA1D4EF01--