From owner-freebsd-arch@FreeBSD.ORG Sun Aug 15 16:45:47 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6656A1065696; Sun, 15 Aug 2010 16:45:47 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 481DF8FC0A; Sun, 15 Aug 2010 16:45:47 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id BC15B5B04; Sun, 15 Aug 2010 09:27:30 -0700 (PDT) To: Bruce Evans In-reply-to: Your message of "Fri, 13 Aug 2010 19:46:42 +1000." <20100813191149.V12776@delplex.bde.org> References: <20100813191149.V12776@delplex.bde.org> Comments: In-reply-to Bruce Evans message dated "Fri, 13 Aug 2010 19:46:42 +1000." Date: Sun, 15 Aug 2010 09:27:30 -0700 From: Bakul Shah Message-Id: <20100815162730.BC15B5B04@mail.bitblocks.com> Cc: mdf@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 16:45:47 -0000 On Fri, 13 Aug 2010 19:46:42 +1000 Bruce Evans wrote: > > I prefer to fix printf. There should be a %I format something like in > sfio. Unfortunately C99 only standardized the PRI* mistake. I never > learned exactly what %I does, but think it should have 2 variations, > something like a plain %I causing the compiler to rewrite the literal > format string, replacing %I with the appropriate Standard format, and > %I for interpretation by the library. -Wformat has done all the > work needed to determine the correct replacement for 10-20 years. So > vm_offset's and size_t's would normally be printed using "%I[xu]" (no > need for %z), but in message catalogues they would be printed using > > ("...%I*[xu] %I*[xu]...", ... > sizeof(vm_offset_t) * CHAR_BIT, var_of_type_vm_offset_t, > sizeof(size_t) * CHAR_BIT, var_of_type_vm_offset_t, ...) > > Except that came out too painful (almost as bad as using PRI*). I > think I would usually avoid using %I if it were as messy as > this, and use %j and require all integer args to be of type [u]intmax_t. > > %I could also be a more global directive (either at the front of every > literal format string that wants rewriting for all args, or in CFLAGS > for all strings in a file). Have you looked at plan9's fmtinstall(3)? Basically fmtinstall('x', foo) will install function foo to be called when %...x is seen in a format string. foo takes struct Fmt* which points to stuff needed for formatting. Things like width, precision, flags, whether output buffer is runes or chars etc. Once you install the formats you need, their use becomes pretty painless. Perhaps kernel's printf can be extended (or rebuilt) using this idea? Seems to me something like that would be better and much more extensible than inflicting %I*[xu]. This does not require compiler magic but you also lose the -Wformat crutch. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 16 03:27:58 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B8C1065675; Mon, 16 Aug 2010 03:27:58 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 84D478FC08; Mon, 16 Aug 2010 03:27:58 +0000 (UTC) Received: from f8x64.laiers.local (dslb-088-066-055-237.pools.arcor-ip.net [88.66.55.237]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MY4Jc-1OOtRq1BcO-00VFsY; Mon, 16 Aug 2010 05:15:22 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Mon, 16 Aug 2010 05:15:21 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_J1KaMsyD3+FF4Et" Message-Id: <201008160515.21412.max@love2party.net> X-Provags-ID: V02:K0:DIikoG3G/hgyOlN1y4ofMSxiKRb1XkAV/7QBNAZ9U0o +GrE2nnBYMDKWQLHpkx8rSL/J8yvPN0YRay/Da235FbUfosO+n lfDLjSgqtOLCcZ/Kwx3o4oW/lFjXtDC6hfGvju2wP8BDLvpjFy ExQukxlxL7weNCSeNhqPow62fi9KHqkUeCZhIFgQEhyp8jxwSF RJoYHH0X7XczYPDJZK98A== Cc: ups@freebsd.org Subject: rmlock(9) two additions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 03:27:58 -0000 --Boundary-00=_J1KaMsyD3+FF4Et Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'd like to run two additions to rmlock(9) by you: 1) See the attached patch. It adds rm_try_rlock() which avoids taking the mutex if the lock is currently in a write episode. The only overhead to the hot path is an additional argument and a return value for _rm_rlock*. If you are worried about that, it can obviously be done in a separate code path, but I reckon it not worth the code crunch. Finally, there is one additional branch to check the "trylock" argument, but that's well past the hot path. 2) No code for this yet - testing the waters first. I'd like to add the ability to replace the mutex for writer synchronization with a general lock - especially to be able to use a sx(9) lock here. The reason for #2 is the following use case in a debugging facility: "reader": if (rm_try_rlock()) { grab_per_cpu_buffer(); fill_per_cpu_buffer(); rm_runlock(); } "writer" - better exclusive access thread: rm_wlock(); collect_buffers_and_copy_out_to_userspace(); rm_wunlock(); This is much cleaner and possibly cheaper than the various hand rolled versions I've come across, that try to get the same synchronization with atomic operations. If we could sleep with the wlock held, we can also avoid copying the buffer contents, or swapping buffers. Is there any concern about either of this? Any objection? Input? Thanks, Max Laier --Boundary-00=_J1KaMsyD3+FF4Et Content-Type: text/x-patch; charset="ISO-8859-1"; name="rm_try_rlock.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rm_try_rlock.diff" diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c index a6a622e..9b91fb1 100644 --- a/sys/kern/kern_rmlock.c +++ b/sys/kern/kern_rmlock.c @@ -241,8 +241,8 @@ rm_sysinit_flags(void *arg) rm_init_flags(args->ra_rm, args->ra_desc, args->ra_opts); } -static void -_rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) +static int +_rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) { struct pcpu *pc; struct rm_queue *queue; @@ -254,7 +254,7 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) /* Check if we just need to do a proper critical_exit. */ if (0 == rm->rm_noreadtoken) { critical_exit(); - return; + return (1); } /* Remove our tracker from the per-cpu list. */ @@ -265,7 +265,7 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) /* Just add back tracker - we hold the lock. */ rm_tracker_add(pc, tracker); critical_exit(); - return; + return (1); } /* @@ -289,7 +289,7 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) mtx_unlock_spin(&rm_spinlock); rm_tracker_add(pc, tracker); critical_exit(); - return; + return (1); } } } @@ -297,6 +297,9 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) sched_unpin(); critical_exit(); + if (trylock) + return (0); + mtx_lock(&rm->rm_lock); rm->rm_noreadtoken = 0; critical_enter(); @@ -307,10 +310,12 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) critical_exit(); mtx_unlock(&rm->rm_lock); + + return (1); } -void -_rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker) +int +_rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) { struct thread *td = curthread; struct pcpu *pc; @@ -338,10 +343,10 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker) * conditional jump. */ if (0 == (td->td_owepreempt | rm->rm_noreadtoken)) - return; + return (1); /* We do not have a read token and need to acquire one. */ - _rm_rlock_hard(rm, tracker); + return _rm_rlock_hard(rm, tracker, trylock); } static void @@ -470,20 +475,23 @@ _rm_wunlock_debug(struct rmlock *rm, const char *file, int line) _rm_wunlock(rm); } -void +int _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, - const char *file, int line) + int trylock, const char *file, int line) { - WITNESS_CHECKORDER(&rm->lock_object, LOP_NEWORDER, file, line, NULL); - _rm_rlock(rm, tracker); + if (_rm_rlock(rm, tracker, trylock)) { + LOCK_LOG_LOCK("RMRLOCK", &rm->lock_object, 0, 0, file, line); - LOCK_LOG_LOCK("RMRLOCK", &rm->lock_object, 0, 0, file, line); + WITNESS_LOCK(&rm->lock_object, 0, file, line); - WITNESS_LOCK(&rm->lock_object, 0, file, line); + curthread->td_locks++; - curthread->td_locks++; + return (1); + } + + return (0); } void @@ -517,12 +525,12 @@ _rm_wunlock_debug(struct rmlock *rm, const char *file, int line) _rm_wunlock(rm); } -void +int _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, - const char *file, int line) + int trylock, const char *file, int line) { - _rm_rlock(rm, tracker); + return _rm_rlock(rm, tracker, trylock); } void diff --git a/sys/sys/rmlock.h b/sys/sys/rmlock.h index 9766f67..5261bcf 100644 --- a/sys/sys/rmlock.h +++ b/sys/sys/rmlock.h @@ -53,14 +53,15 @@ void rm_sysinit_flags(void *arg); void _rm_wlock_debug(struct rmlock *rm, const char *file, int line); void _rm_wunlock_debug(struct rmlock *rm, const char *file, int line); -void _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, - const char *file, int line); +int _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, + int trylock, const char *file, int line); void _rm_runlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, const char *file, int line); void _rm_wlock(struct rmlock *rm); void _rm_wunlock(struct rmlock *rm); -void _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker); +int _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, + int trylock); void _rm_runlock(struct rmlock *rm, struct rm_priotracker *tracker); /* @@ -74,14 +75,17 @@ void _rm_runlock(struct rmlock *rm, struct rm_priotracker *tracker); #define rm_wlock(rm) _rm_wlock_debug((rm), LOCK_FILE, LOCK_LINE) #define rm_wunlock(rm) _rm_wunlock_debug((rm), LOCK_FILE, LOCK_LINE) #define rm_rlock(rm,tracker) \ - _rm_rlock_debug((rm),(tracker), LOCK_FILE, LOCK_LINE ) + ((void)_rm_rlock_debug((rm),(tracker), 0, LOCK_FILE, LOCK_LINE )) +#define rm_try_rlock(rm,tracker) \ + _rm_rlock_debug((rm),(tracker), 1, LOCK_FILE, LOCK_LINE ) #define rm_runlock(rm,tracker) \ _rm_runlock_debug((rm), (tracker), LOCK_FILE, LOCK_LINE ) #else -#define rm_wlock(rm) _rm_wlock((rm)) -#define rm_wunlock(rm) _rm_wunlock((rm)) -#define rm_rlock(rm,tracker) _rm_rlock((rm),(tracker)) -#define rm_runlock(rm,tracker) _rm_runlock((rm), (tracker)) +#define rm_wlock(rm) _rm_wlock((rm)) +#define rm_wunlock(rm) _rm_wunlock((rm)) +#define rm_rlock(rm,tracker) ((void)_rm_rlock((rm),(tracker), 0)) +#define rm_try_rlock(rm,tracker) _rm_rlock((rm),(tracker), 1) +#define rm_runlock(rm,tracker) _rm_runlock((rm), (tracker)) #endif struct rm_args { --Boundary-00=_J1KaMsyD3+FF4Et-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 16 10:29:26 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE411065675; Mon, 16 Aug 2010 10:29:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id A98978FC1D; Mon, 16 Aug 2010 10:29:25 +0000 (UTC) Received: from besplex.bde.org (c122-106-147-41.carlnfd1.nsw.optusnet.com.au [122.106.147.41]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7GASrPc024913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 20:28:56 +1000 Date: Mon, 16 Aug 2010 20:28:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bakul Shah In-Reply-To: <20100815162730.BC15B5B04@mail.bitblocks.com> Message-ID: <20100816193035.A896@besplex.bde.org> References: <20100813191149.V12776@delplex.bde.org> <20100815162730.BC15B5B04@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mdf@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 10:29:26 -0000 On Sun, 15 Aug 2010, Bakul Shah wrote: > On Fri, 13 Aug 2010 19:46:42 +1000 Bruce Evans wrote: >> >> I prefer to fix printf. There should be a %I format something like in >> sfio. Unfortunately C99 only standardized the PRI* mistake. I never >> learned exactly what %I does, but think it should have 2 variations, >> something like a plain %I causing the compiler to rewrite the literal >> format string, replacing %I with the appropriate Standard format, and >> %I for interpretation by the library. -Wformat has done all the >> work needed to determine the correct replacement for 10-20 years. So >> vm_offset's and size_t's would normally be printed using "%I[xu]" (no >> need for %z), but in message catalogues they would be printed using >> >> ("...%I*[xu] %I*[xu]...", ... >> sizeof(vm_offset_t) * CHAR_BIT, var_of_type_vm_offset_t, >> sizeof(size_t) * CHAR_BIT, var_of_type_vm_offset_t, ...) >> >> Except that came out too painful (almost as bad as using PRI*). I >> think I would usually avoid using %I if it were as messy as >> this, and use %j and require all integer args to be of type [u]intmax_t. >> >> %I could also be a more global directive (either at the front of every >> literal format string that wants rewriting for all args, or in CFLAGS >> for all strings in a file). > > Have you looked at plan9's fmtinstall(3)? Basically No, but it doesn't sound too good. > fmtinstall('x', foo) will install function foo to be called > when %...x is seen in a format string. foo takes struct Fmt* > which points to stuff needed for formatting. Things like > width, precision, flags, whether output buffer is runes or > chars etc. Once you install the formats you need, their use > becomes pretty painless. Perhaps kernel's printf can be How is this painless? The user still has the burden of making the variadic arg match 'x'. You can casts all variadic args to a small subset of common types (standard ones and fmtinstalled() ones), but you can do that for ordinary printf() too. > extended (or rebuilt) using this idea? Seems to me something > like that would be better and much more extensible than > inflicting %I*[xu]. This does not require compiler magic but > you also lose the -Wformat crutch. So you have hundreds if not thousands more possibilities for type mismatches (1 for each fmtinstall()'ed foo), and no way to check them). -Wformat is better. FreeBSD also has fmtcheck(), which does dynamic checking and thus shares some problems with fmtinstall() (it doesn't extend, but would be more needed with dynamic extension, but it is already missing too much of what -Wformat does and would be missing more with dynamic extension). %I* is painful, but not plain %I. Compiler magic is the right way. Another way that is not painless but is perfectly portable and only depends on compiler magic for optimizations is to conventially cast all args to a common maximal type. Code like: printf("int: %jd unsigned: %ju: FP %Lf\n", (intmax_t)i, (uintmax_t)u, (long double)f); may be unnecessarily inefficient (i might by 8 bits and intmax_t might be 1024 bits). However, printf() is a standard function so the compiler printf("int: %d unsigned: %u: FP %f\n", i, u, f); if it knows that the default promotion of i is int, etc. gcc already does the related optimization of replacing printf("foo\n") by puts("foo"), and it should also replace a big printf by lots of little ones with a special function for each arg if that were actually an optimization. The analysis for this is essentially what is done by -Wformat. This is still painful to read and write because it requires the programmer to figure out the default promotion of each arg and write out all the casts explicitly; then readers have to read all the casts. %I in the format string is essentially a short way of figuring out, writing and reading these casts. Another way that doesn't quite work without compiler magic is to have a non-variadic printf which takes only args of common maximal types: xprintf("int: %d unsigned: %u: FP %f\n", i, u, f); Here %d, %u and %f means the maximal specifiers %jd, %ju and %Lf, respectively, not the usual specifiers, and xprintf() has the magic prototype xprintf(const char * restrict fmt, ^^^) which says that all variadic args are to be (as if) promoted to their maximal type. There is a minor problem with args like field widths that don't need promotion (however, this problem is a feature too, since it avoids the common printf format error of passing an uncast size_t for a field width). The `as if' rule allows reducing xprintf() to printf() as above, or avoiding promotion for field widths only. Note that K&R functions have a similar problem with requiring either too many casts, or manual matching of arg types with parameter types, or both. This was fixed using compiler magic named prototypes (except allowing downcasting and crosscasting without a diagnostics gives man new bugs). Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Aug 16 21:16:01 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A09F1065695; Mon, 16 Aug 2010 21:16:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DDAC68FC23; Mon, 16 Aug 2010 21:16:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B04A646B0D; Mon, 16 Aug 2010 17:15:58 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DAC628A03C; Mon, 16 Aug 2010 17:15:57 -0400 (EDT) From: John Baldwin To: mdf@freebsd.org Date: Mon, 16 Aug 2010 16:01:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <4C656275.30201@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008161601.04203.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 16 Aug 2010 17:15:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:16:01 -0000 On Friday, August 13, 2010 12:34:23 pm mdf@freebsd.org wrote: > On Fri, Aug 13, 2010 at 3:19 PM, John Baldwin wrote: > > mdf@FreeBSD.org wrote: > >> > >> Looking over the arch-specific definitions, using uintptr_t and size_t > >> would not affect the actual width of these sizes. However, it would > >> simplify e.g. conformant printf(9) statements, since there is an > >> approved specifier for size_t and, while there isn't one for > >> uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better > >> specifier)? > >> > >> Admittedly, this isn't the simplest of undertakings, as there are 590 > >> instances of vm_size_t in the FreeBSD source code and 3887 of > >> vm_offset_t. > >> > >> Has this proposal made the rounds before and been shot down for some > >> reason? > > > > Hmm, I suspect vm_offset_t predates uintptr_t. I'm not sure the churn is > > really worth the effort involved especially as regards conflicts in future > > MFC's, etc. You also forgot vm_ooffset_t -> off_t. However, how often are > > vm_*_t values printed outside of temporary debug statements? They shouldn't > > be used in userland, so I'm not sure if there are enough printf() > > invocations to really justify the churn. > > Well, it wasn't just about printf, but that's one (potential) > justification that Bruce shot down. :-) > > My thinking was also that the types did predate the C99 "standard" > types that represent the same things. > > There seem to be fewer typedef's in FreeBSD than e.g. AIX; for > example, cpu identifiers are alternately int or u_int, but there's no > cpu_t type that is guaranteed wide enough to hold mp_maxid. short > would be sufficient for the near future and also allows for -1 to > represent an out-of-band value. > > cpu_t is just one example of a "missing" typedef, though I can't > recall any others at the moment. Given that, I was under the vague > assumption that FreeBSD preferred to use base types where possible > instead of typedefs, as a project. > > This discussion has been very helpful for me to learn from. FreeBSD is hesitant to add new foo_t typedefs. style(9) basically forbids adding ones unless they are mandated by a standard. I think in the case of the VM types, it is case of preserving the "feel" of the Mach VM code. For better or worse large sweeps of "style" fixes are generally not encouraged either, and I think this would fall into that category. The cpuid type thing is quite a sordid affair at the moment. The canonical type for CPU IDs is actually a u_char (see td_oncpu) with a NOCPU constant (0xff) used to denote an out-of-band value. Some newer APIs use 'int' instead I think due to making room for larger CPU ID values than fit in a u_char. I would probably settle on 'int' myself and not bother with a 'short'. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Aug 17 12:32:33 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A059C10656A4; Tue, 17 Aug 2010 12:32:33 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D58D8FC16; Tue, 17 Aug 2010 12:32:32 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o7HCWFPs069170; Tue, 17 Aug 2010 14:32:31 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o7HCWF7p069169; Tue, 17 Aug 2010 14:32:15 +0200 (CEST) (envelope-from olli) Date: Tue, 17 Aug 2010 14:32:15 +0200 (CEST) Message-Id: <201008171232.o7HCWF7p069169@lurza.secnetix.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG, jhb@FreeBSD.ORG, mdf@FreeBSD.ORG In-Reply-To: <201008161601.04203.jhb@freebsd.org> X-Newsgroups: list.freebsd-arch User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Tue, 17 Aug 2010 14:32:31 +0200 (CEST) Cc: Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with ?size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.ORG, jhb@FreeBSD.ORG, mdf@FreeBSD.ORG List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:32:33 -0000 John Baldwin wrote: > The cpuid type thing is quite a sordid affair at the moment. The canonical > type for CPU IDs is actually a u_char (see td_oncpu) with a NOCPU constant > (0xff) used to denote an out-of-band value. Some newer APIs use 'int' > instead I think due to making room for larger CPU ID values than fit in a > u_char. I would probably settle on 'int' myself and not bother with a > 'short'. Just an observation: Machines that could -- in theory -- run FreeBSD are already quickly approaching that u_char limit for the CPU ID. For example, the Sun Fire X4800 (quite common in larger data centers) supports eight Xeon 7500 packages which have eight cores plus hyperthreading, which gives a 128-way SMP system. Solaris, Linux and Windows support them, FreeBSD doesn't. (This is not related to u_char CPU ID, though, but rather to cpumask_t.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 15:27:51 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF78106564A; Wed, 18 Aug 2010 15:27:51 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAD88FC23; Wed, 18 Aug 2010 15:27:51 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id o7IFReO0064574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 00:27:45 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 19 Aug 2010 00:27:40 +0900 Message-ID: From: Hajimu UMEMOTO To: arch@freebsd.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.1-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 19 Aug 2010 00:27:45 +0900 (JST) X-Virus-Scanned: clamav-milter 0.96.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: current@freebsd.org Subject: CFR: importing openresolv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:27:51 -0000 Hi, I wish to import openresolv 3.3.5 into our base tree. It makes merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ... into /etc/resolv.conf easier. http://roy.marples.name/projects/openresolv My patch against 9-CURRENT can be obtained from: http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.diff.gz Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 16:48:22 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC7F710656A6; Wed, 18 Aug 2010 16:48:22 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4308FC0A; Wed, 18 Aug 2010 16:48:21 +0000 (UTC) Received: by wwb24 with SMTP id 24so944957wwb.31 for ; Wed, 18 Aug 2010 09:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:content-type :x-mailer:message-id:date:to:content-transfer-encoding:mime-version; bh=zqpyBbi/ndL6q/YbP51DVZNpolF79fknmdqMO+thyn8=; b=dY1m9xwyqCVKYRXsqhEj4a0xbsUDPUSx1b19SSxQJpjwaghFxpAR9jFqofb8GGLeIa sERu8NRJulX4Nxv/qbBcLffAuhtabcNjQXVWONdcAKW/VI1Ybor83zCxBE5Iqx4O5ebU m+eetC5I1BGXytgLizUCM7P3zXgqPqujECjIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; b=i2m3Sh98cjnb7sC4lFUpnN/PiaZSM60jml9QwEjbeC5qG3H666i5JxXKE5WFul087+ i+Loid8Lt/rmCWVF+nUuBqMYTsvnfWuwtNkwIVJw379o9kkDGHGBR5/AWFcMp2xsXN1W fcWZyoFhRwwUB4Hw6N73mu86124GTeXKifyhs= Received: by 10.227.72.213 with SMTP id n21mr7390335wbj.66.1282148701624; Wed, 18 Aug 2010 09:25:01 -0700 (PDT) Received: from [77.54.24.165] (165.24.54.77.rev.vodafone.pt [77.54.24.165]) by mx.google.com with ESMTPS id a28sm376374wbe.21.2010.08.18.09.24.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 09:25:00 -0700 (PDT) From: Rui Paulo Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8A400) Message-Id: Date: Wed, 18 Aug 2010 17:23:50 +0100 To: "arch@freebsd.org" , "current@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 8A400) Cc: Subject: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:48:22 -0000 Hi, I've been chatting with the ICC ex-users and they seem to be ok with the rem= oval of the ICC bits from share/mk and other places.=20 The reason is that it doesn't work and no one has volunteered to fix it for m= any years. This seems to indicate that the interest in ICC is low.=20 If there's anyone against this, speak now or forever be silent. :-) -- Rui Paulo= From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 17:45:49 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F0A51065697; Wed, 18 Aug 2010 17:45:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9758D8FC1C; Wed, 18 Aug 2010 17:45:48 +0000 (UTC) Received: by bwz20 with SMTP id 20so1048629bwz.13 for ; Wed, 18 Aug 2010 10:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=oco37uhWHPS15IL89HVZos8k6wqtaYFmygBhWJS2N7k=; b=GlxG8c7H2jvRmXofnIbSou7C6tGbbV3aVueiP2/HQuyridaUbcMnl8fpAwbdsZw6wP 7RAydiPUKkQ2Y7AlD0aX2IsfDdrgPQ4U8gSw/nlpgUbeNiJalIROMnnXOfE/fv4aPtt7 llBEGB55d+iPGUjUDBcyy6RmJE85gkuivMiZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=nrb6d42m9eNS6dlmmQzkVp07XGpeYCh0itsbqXXHu7IzXsabD7aw6a7PBKbwZ6BkoJ j+JHiiwiS18jFdN8AEaTrUo8GphaERlOXah3aud1VTPTd3fWTaYVj7joZ2SeCLb/91xz vPMD0xxIQBPR00p/tJPlMVWe22e/cNyCx0M/M= MIME-Version: 1.0 Received: by 10.204.47.193 with SMTP id o1mr5659420bkf.134.1282151924459; Wed, 18 Aug 2010 10:18:44 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Wed, 18 Aug 2010 10:18:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 10:18:44 -0700 X-Google-Sender-Auth: q2fieduYVMFfXkP8Y5AWbZ4Z1Oo Message-ID: From: Garrett Cooper To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:45:49 -0000 On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: > Hi, > I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. > The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. > If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 17:48:00 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD9501065672; Wed, 18 Aug 2010 17:48:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3BFA48FC13; Wed, 18 Aug 2010 17:48:00 +0000 (UTC) Received: by bwz20 with SMTP id 20so1050967bwz.13 for ; Wed, 18 Aug 2010 10:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pEppfNykRnKcB2kHv5rC5lJi1XX/9WsatuFvcIAocJc=; b=lwWtREhJwLCSl4A+M8ZYuo7cOrZPuJB9TKrz53kfbaNpDbeGvId1SoN3BEaulHcETQ vrhGkZBgLndg6Dy9d2wf6zmC9Uxg7CZwN9uwwsfJldcPLhiNJO61hOLSKfho1gQRiitY JRLqeeRyYphaTiO08+xLxncAcy4Ssuh+InCF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=J6L/h3LeuaUKrDsPRwN6vPyzZWBOeGimr3/uVNeOdeG178MI9ou57VAIS1aAb751vO 4yk8EiLgOXg24/u3gRm4riLVkTdD+pbRhefGa5ngkKqTfS6ysvIOVIhzgnK9trhibm1h tIoBxb96T7UrujPZpIdmtbVpyssXYlNdLcIqc= MIME-Version: 1.0 Received: by 10.204.45.213 with SMTP id g21mr5732851bkf.11.1282151950585; Wed, 18 Aug 2010 10:19:10 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Wed, 18 Aug 2010 10:19:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 10:19:10 -0700 X-Google-Sender-Auth: X3OP727PaO3lu0RGBkp4GjTtJi4 Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rui Paulo , "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:48:01 -0000 On Wed, Aug 18, 2010 at 10:18 AM, Garrett Cooper wrot= e: > On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >> Hi, >> I've been chatting with the ICC ex-users and they seem to be ok with the= removal of the ICC bits from share/mk and other places. >> The reason is that it doesn't work and no one has volunteered to fix it = for many years. This seems to indicate that the interest in ICC is low. >> If there's anyone against this, speak now or forever be silent. :-) > > =A0 =A0Later versions of icc are more gcc compliant aren't they? If so, Sorry -- wrong term. s/compliant/compatible/ :). > wouldn't this also be a non-issue to remove the bits, or are there > still some incompatibilities between gcc and icc that are worth > noting? > Thanks, > -Garrett > From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 17:56:45 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9159910656A7; Wed, 18 Aug 2010 17:56:45 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 523CB8FC1E; Wed, 18 Aug 2010 17:56:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911] (unknown [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A16895C59; Wed, 18 Aug 2010 19:56:44 +0200 (CEST) Message-ID: <4C6C1EDC.5000206@andric.com> Date: Wed, 18 Aug 2010 19:56:44 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Rui Paulo References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> In-Reply-To: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:56:45 -0000 On 2010-08-18 19:37, Rui Paulo wrote: > I really don't know how compatible is the latest icc because no one > ever updated the ports version. This is actually a hint that no one > really uses this anymore. I recently installed the port, which has icc 8.1, but it fails to compile even simple C++ programs, because it cannot cope with the libstdc++ headers from g++ 4.2.1. You have to do all kinds of tricks, such as installing the gcc 3.4.x port, and pointing the Intel compiler to its libstdc++ headers and libraries, or nothing will work. Updating that port to icc 11.1 is probably not a trivial task, and making sure it compiles programs properly is even trickier... :) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 18:09:52 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEBC910656ED; Wed, 18 Aug 2010 18:09:52 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id AF2D58FC26; Wed, 18 Aug 2010 18:09:52 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 7CCA411B80D; Wed, 18 Aug 2010 12:37:46 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id C095RT4RC0AQ; Wed, 18 Aug 2010 12:37:46 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Wed, 18 Aug 2010 18:37:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> References: To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:09:53 -0000 On 18 Aug 2010, at 18:18, Garrett Cooper wrote: > On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >> Hi, >> I've been chatting with the ICC ex-users and they seem to be ok with = the removal of the ICC bits from share/mk and other places. >> The reason is that it doesn't work and no one has volunteered to fix = it for many years. This seems to indicate that the interest in ICC is = low. >> If there's anyone against this, speak now or forever be silent. :-) >=20 > Later versions of icc are more gcc compliant aren't they? If so, > wouldn't this also be a non-issue to remove the bits, or are there > still some incompatibilities between gcc and icc that are worth > noting? I really don't know how compatible is the latest icc because no one ever = updated the ports version. This is actually a hint that no one really = uses this anymore. Regards, -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 18:14:48 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48AD9106566B; Wed, 18 Aug 2010 18:14:48 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id F311A8FC12; Wed, 18 Aug 2010 18:14:47 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 3BAED14DC6E7; Wed, 18 Aug 2010 19:56:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VG2GuWdfnlHa; Wed, 18 Aug 2010 19:56:04 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 72FEC14DC315; Wed, 18 Aug 2010 19:56:04 +0200 (CEST) Message-ID: <4C6C1EB1.5000004@FreeBSD.org> Date: Wed, 18 Aug 2010 19:56:01 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rui Paulo References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> In-Reply-To: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , netchild@FreeBSD.org, "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:14:48 -0000 Em 2010.08.18. 19:37, Rui Paulo escreveu: > On 18 Aug 2010, at 18:18, Garrett Cooper wrote: > >> On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >>> Hi, >>> I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. >>> The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. >>> If there's anyone against this, speak now or forever be silent. :-) >> Later versions of icc are more gcc compliant aren't they? If so, >> wouldn't this also be a non-issue to remove the bits, or are there >> still some incompatibilities between gcc and icc that are worth >> noting? > I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. IIRC, apart from the low interest, the problem was that because of ICC's license using ICC to test this mk stuff requires a commercial license because somehow it is considered a derivative work. It has also prevented us from providing better support. In 2006, I wanted to do some progress as part of my SoC project because that time there was more interest. Alexander (CC'd) may comment on this. I think he has a license for FreeBSD work but he is not allowed to give it out to a third party. Gabor From owner-freebsd-arch@FreeBSD.ORG Wed Aug 18 19:59:53 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F131065670; Wed, 18 Aug 2010 19:59:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B70EB8FC21; Wed, 18 Aug 2010 19:59:52 +0000 (UTC) Received: by bwz20 with SMTP id 20so1198266bwz.13 for ; Wed, 18 Aug 2010 12:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=XHVsloaaPABMDShXzc0KK8EWW72NW25HyrNBuGnnGaM=; b=ToJjlYjiwarxeFDkHYNercM6fgcT/TmpTOdOeOMwHt2/iJZPRw1/L7GqADuTszW1Xy kezNwnUgGqYCNIpdNucMtGG9M5I+sKqHGHfiUSAjohLeh9w9UFuWVOslh/G9YupHctyL ZjxBTa8J7eJ0KOTdj/Cb+O9VY4meujp3BupmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=MPUNLC/f17HAWDq2deR5Gyqh4iE+yyGa59BATG40xWYZQ+EEzypVGTDvbFKo00GVrl i/kSa86Y1zWMkUCHxHvgiyvQGE1DwNMkOeSgj0opqlL/dh8aLZIypGAbyhTRe/kBltiw 3NX6aPhPPm29lZh/Srps8OIR4ZNgQbg3/uNe8= MIME-Version: 1.0 Received: by 10.204.47.193 with SMTP id o1mr5793031bkf.134.1282161591407; Wed, 18 Aug 2010 12:59:51 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Wed, 18 Aug 2010 12:59:51 -0700 (PDT) In-Reply-To: <4C6C1EDC.5000206@andric.com> References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EDC.5000206@andric.com> Date: Wed, 18 Aug 2010 12:59:51 -0700 X-Google-Sender-Auth: pqm0BuWAGCn8P-SCe380Zo0eULU Message-ID: From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: "arch@freebsd.org" , Rui Paulo , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:59:53 -0000 On Wed, Aug 18, 2010 at 10:56 AM, Dimitry Andric wrote: > On 2010-08-18 19:37, Rui Paulo wrote: >> I really don't know how compatible is the latest icc because no one >> ever updated the ports version. This is actually a hint that no one >> really uses this anymore. > > I recently installed the port, which has icc 8.1, but it fails to > compile even simple C++ programs, because it cannot cope with the > libstdc++ headers from g++ 4.2.1. > > You have to do all kinds of tricks, such as installing the gcc 3.4.x > port, and pointing the Intel compiler to its libstdc++ headers and > libraries, or nothing will work. > > Updating that port to icc 11.1 is probably not a trivial task, and > making sure it compiles programs properly is even trickier... :) Yeah... I was referring to icc 11.x because of work that my old group was looking at doing back when I was working on Linux. Anything older than that probably has compatibility issues :). Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 07:01:39 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 071221065675; Thu, 19 Aug 2010 07:01:39 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 807D48FC1A; Thu, 19 Aug 2010 07:01:38 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9D48F844010; Thu, 19 Aug 2010 09:01:32 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 7D8D7121D; Thu, 19 Aug 2010 09:01:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282201289; bh=bTfdyjSJASlRVuoCiqXwl6+tv7TATDAJKCG92SC/tDg=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tpo0/9BltALan4JAn8BKXEgEkpSrM2103t5PHypsqy7GeB0oJ7E3pW72/KLVSzCP0 leVwb6OjqsSEvlkO/VxJFEjQFBqBMqx76qcZOu5JNfkwxAilexXJbRs4hRv8GwNlgJ ugiOPQZ5ipuyOdCU3Jmvj8PFanHcZkxJntfYzNabXd+HYb8phRqs70CkkKSrPomiEv Lxnt350CLxu52vTzseAH1PLHThaRSswNT85JPl5MDo1bncZIosdYLY7Ic5TTroRO+I NeNgxlJMI2+t7gKNlTEXCHnvpLLQlRAClSnoB1Q+nQTgc+ocDkj3bmXKppAYUxw0uz Fuy5mKP+coXnQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J71TtV063469; Thu, 19 Aug 2010 09:01:29 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 09:01:28 +0200 Message-ID: <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> Date: Thu, 19 Aug 2010 09:01:28 +0200 From: Alexander Leidinger To: Gabor Kovesdan References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> In-Reply-To: <4C6C1EB1.5000004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9D48F844010.A3BB8 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282806096.07128@jHNj0DEEXL94bT1D83Y40g X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , Rui Paulo , "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:01:39 -0000 Quoting Gabor Kovesdan (from Wed, 18 Aug 2010 19:56:01 +0200): > Em 2010.08.18. 19:37, Rui Paulo escreveu: >> On 18 Aug 2010, at 18:18, Garrett Cooper wrote: >> >>> On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >>>> Hi, >>>> I've been chatting with the ICC ex-users and they seem to be ok >>>> with the removal of the ICC bits from share/mk and other places. >>>> The reason is that it doesn't work and no one has volunteered to >>>> fix it for many years. This seems to indicate that the interest >>>> in ICC is low. >>>> If there's anyone against this, speak now or forever be silent. :-) >>> Later versions of icc are more gcc compliant aren't they? If so, >>> wouldn't this also be a non-issue to remove the bits, or are there >>> still some incompatibilities between gcc and icc that are worth >>> noting? >> I really don't know how compatible is the latest icc because no one >> ever updated the ports version. This is actually a hint that no one >> really uses this anymore. > IIRC, apart from the low interest, the problem was that because of > ICC's license using ICC to test this mk stuff requires a commercial > license because somehow it is considered a derivative work. It has If we wanted to ship binaries, we would have to compile them with the commercial license. > also prevented us from providing better support. In 2006, I wanted > to do some progress as part of my SoC project because that time > there was more interest. Alexander (CC'd) may comment on this. I > think he has a license for FreeBSD work but he is not allowed to > give it out to a third party. At some point I got a license (IIRC for 2-users) which could have been installed in the cluster, but this would have meant to install a license server somewhere. The license was also the only commercial license I had which would have allowed to run the amd64... ehrm... em64t version of icc. This was for icc 9.x and I have some doubts this license will work with icc 11.x. If someone would get icc 11.x up and runnig as a port (similar to what we have for outdated icc version in the ports collection), I would have a look if my contact at Intel is still working there in a position which allows him to get a commercial license for us. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The happiest time in any man's life is just after the first divorce. -- J. K. Galbraith From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 07:08:33 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EAF4106566B; Thu, 19 Aug 2010 07:08:33 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 25B2C8FC0A; Thu, 19 Aug 2010 07:08:32 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id A5D9F844010; Thu, 19 Aug 2010 08:49:55 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 3D5CF121A; Thu, 19 Aug 2010 08:49:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282200592; bh=gJ4qzPmXXI8Qx2BjJEHMUqCjoZqkDMiydv8NwggM0t0=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Sc7lB4/uFHNhsVgq6/P8J7tebYLsqdTH8UGTlqMphTPFBEbpKyHA3DTnahl0WuC4r iZrl/I4+amEyDKl6A626zg+up5lQEIhWF+dFCnYWzFayVZLB7qeFqRhC7Tn4Y43pdX dSoCyEIVFfM7PM+FpLTx7T+5kkqW1zXa5p4Je3tOre8ZCV21rz44Q1a7/IrR/LIysV pr5+xEPPDMu9GV+7zd4cRiqcFOpHE8YbyBztWkn45qBAia9KSxKHRGUB1T5i3OjRD6 dmbH7bR4GQjKaSA6H1psW8vpx2wPhCqLbNCuS+nxQVkXlYltemAYqKCykVUoFurL1r fXZupDq4Deiow== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J6npCi060562; Thu, 19 Aug 2010 08:49:51 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 08:49:51 +0200 Message-ID: <20100819084951.17534pzw4h7ff8kk@webmail.leidinger.net> Date: Thu, 19 Aug 2010 08:49:51 +0200 From: Alexander Leidinger To: Dimitry Andric References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EDC.5000206@andric.com> In-Reply-To: <4C6C1EDC.5000206@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: A5D9F844010.A456C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282805397.60455@PSIoOQN3UvfgRNVLR9XL8Q X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , Rui Paulo , "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:08:33 -0000 Quoting Dimitry Andric (from Wed, 18 Aug 2010 19:56:44 +0200): > Updating that port to icc 11.1 is probably not a trivial task, and > making sure it compiles programs properly is even trickier... :) It is not as trivial as a normal "configure;make;make install" port, but with the existing ports already having sorted out a lot of the big problems I think it is more a question of time, interest, and lack of fear for doing it (I'm available to answer questions -- as far as I remember -- regarding the things being done in the old icc ports, in case someone has time, interest... and no fear). Bye, Alexander. -- Alimony is like buying oats for a dead horse. -- Arthur Baer http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 07:33:24 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A98E1065697; Thu, 19 Aug 2010 07:33:24 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 495BF8FC1A; Thu, 19 Aug 2010 07:33:24 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlzQL-0008NW-5R; Thu, 19 Aug 2010 09:20:29 +0200 Message-ID: <4C6CDB3A.1010200@continum.net> Date: Thu, 19 Aug 2010 09:20:26 +0200 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Leidinger References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> In-Reply-To: <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:33:24 -0000 Hello, Alexander Leidinger wrote: > If someone would get icc 11.x up and runnig as a port (similar to what > we have for outdated icc version in the ports collection), I would have > a look if my contact at Intel is still working there in a position which > allows him to get a commercial license for us. A while ago it was stated by MySQL AB, that their dbms performs about 20% better when compiled with icc instead of gcc. Is this (still) true? Cheers, -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 08:49:21 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFCC510656CB; Thu, 19 Aug 2010 08:49:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6813C8FC18; Thu, 19 Aug 2010 08:49:21 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1F0E784401F; Thu, 19 Aug 2010 10:49:17 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id DC2251228; Thu, 19 Aug 2010 10:49:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282207754; bh=MMnpNYCh9xfNdsRwmim3DMbpeqKZ3GFo3xK0t9w3R+4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QwHwEtv6C3z32G6hMNgcfKYoMRzFUM3K31Fe4CLTUQCQ6kab3HBUzaP0A9iIUW9FY qjwl1gvkswIClqpxyXdyy4zetH3YA0RVklnt/ZU2PbBAqHVTJ39bR/RLgxD7yn37dO nIbKVuO81j+QfNScjWG3dXNukz/D+ByKXTGzqjgHy9t439b28A932PvDfgJwsPJV5t ARWzZgNwqL1m/cB2I89hiM49g/2ijRajzYs6LzaN+p5Vg1i7DvfOLuOjrttd65Z/7P bfXiERsM0OlIl+qVHTZ214DwEPPh0B6sXhnqbVseL278CnVg4CXN+M29rous8E9R+U A9mhM6XvLweiA== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J8nD9B088137; Thu, 19 Aug 2010 10:49:13 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 10:49:13 +0200 Message-ID: <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> Date: Thu, 19 Aug 2010 10:49:13 +0200 From: Alexander Leidinger To: "V. T. Mueller, Continum" References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <4C6CDB3A.1010200@continum.net> In-Reply-To: <4C6CDB3A.1010200@continum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1F0E784401F.A3B5A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282812557.69011@xA28Ox3wydp61jXod2ihPg X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:49:22 -0000 Quoting "V. T. Mueller, Continum" (from Thu, 19 Aug 2010 09:20:26 +0200): > Hello, > > Alexander Leidinger wrote: >> If someone would get icc 11.x up and runnig as a port (similar to >> what we have for outdated icc version in the ports collection), I >> would have a look if my contact at Intel is still working there in >> a position which allows him to get a commercial license for us. > > A while ago it was stated by MySQL AB, that their dbms performs > about 20% better when compiled with icc instead of gcc. Is this > (still) true? This looks overly simplified. "It runs better on CPU X with benchmark Y on Mainboard Z when you use gcc A.B.C with options D and compare it to icc E.F.G with options H." is something you can use in such cases, but it doesn't tell you if it will be the case on your machines with your workload. If you want to know if it is faster on your machines with your workload, then there is only one way to find it out: try it (be warned, due to the amount of optimization options available in gcc/icc, something like this will take a lot of time, as there are a lot of combinations to try). Bye, Alexander. -- Today is the first day of the rest of your life. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 09:15:21 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97F4A106566C; Thu, 19 Aug 2010 09:15:21 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 554E78FC18; Thu, 19 Aug 2010 09:15:21 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1Om1DX-0001Zi-3S; Thu, 19 Aug 2010 11:15:23 +0200 Message-ID: <4C6CF627.20205@continum.net> Date: Thu, 19 Aug 2010 11:15:19 +0200 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Leidinger References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <4C6CDB3A.1010200@continum.net> <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> In-Reply-To: <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:15:21 -0000 Alexander Leidinger wrote: >> Alexander Leidinger wrote: >>> If someone would get icc 11.x up and runnig as a port (similar to >>> what we have for outdated icc version in the ports collection), I >>> would have a look if my contact at Intel is still working there in a >>> position which allows him to get a commercial license for us. >> >> A while ago it was stated by MySQL AB, that their dbms performs about >> 20% better when compiled with icc instead of gcc. Is this (still) true? > > This looks overly simplified. "It runs better on CPU X with benchmark Y > on Mainboard Z when you use gcc A.B.C with options D and compare it to > icc E.F.G with options H." is something you can use in such cases, but > it doesn't tell you if it will be the case on your machines with your > workload. > > If you want to know if it is faster on your machines with your workload, > then there is only one way to find it out: try it (be warned, due to the > amount of optimization options available in gcc/icc, something like this > will take a lot of time, as there are a lot of combinations to try). Sounds reasonable. But doesn't that mean, that there is no need to (take the hassle to) support icc in the future? Especially while folks are being keen on abandon gcc for clang? Cheers vt -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 09:16:26 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D3A106566C; Thu, 19 Aug 2010 09:16:26 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5B88FC13; Thu, 19 Aug 2010 09:16:25 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 6A7681FFC34; Thu, 19 Aug 2010 09:16:24 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B479484559; Thu, 19 Aug 2010 11:16:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> Date: Thu, 19 Aug 2010 11:16:23 +0200 In-Reply-To: <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> (Alexander Leidinger's message of "Thu, 19 Aug 2010 09:01:28 +0200") Message-ID: <86fwybdkt4.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "arch@freebsd.org" , Garrett Cooper , Rui Paulo , Gabor Kovesdan , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:16:26 -0000 Alexander Leidinger writes: > If someone would get icc 11.x up and runnig as a port (similar to what > we have for outdated icc version in the ports collection), I would > have a look if my contact at Intel is still working there in a > position which allows him to get a commercial license for us. Does that really matter? We're not going to start building releases with icc, are we? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 09:35:56 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C721F1065674; Thu, 19 Aug 2010 09:35:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 537D98FC08; Thu, 19 Aug 2010 09:35:56 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9363E84401F; Thu, 19 Aug 2010 11:35:52 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 535E0131D; Thu, 19 Aug 2010 11:35:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282210549; bh=5matR11KF5ijYIveF2wYUB1SdB6xXYhJZOuJA6YgYS0=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U2pSnT4QQtsv8TRNBvfX+lCNbH1mgsvBF3S2LZpWHBOXnoAyhMPDfwcal8Gx3D8+Q Q8zQYMPuJJnv+AO01sjqiEjORFyX9CqN45xzRwqnVsu+Mz+XdEdlPVJx8CX/VY+L6R kvWm0EODBPeF4FolDSwM0GBWgo8r8g2JADZ2QJ24tJAHU5H+YguXFF3E+kEFCjDgW+ DDflFaRqM5P7cpvQQszsTHa7Enp0mZO7rrV5sQWfSYYgii7kC+oOUVKFG1HxCtstg/ 7NxM/PzxYUZ1NPCSf+WDEe9Cc+7/f+VTvLTXZ+5xpjNPrkI2t04v7PWfWDBv2QzTV7 i+Nmj3DxY4u1A== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J9ZmPJ098964; Thu, 19 Aug 2010 11:35:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 11:35:48 +0200 Message-ID: <20100819113548.72614imi2zxx9log@webmail.leidinger.net> Date: Thu, 19 Aug 2010 11:35:48 +0200 From: Alexander Leidinger To: Dag-Erling =?utf-8?b?U23Dg8K4cmdyYXY=?= References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> In-Reply-To: <86fwybdkt4.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9363E84401F.A3A09 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282815354.46504@TNcdKCGoqAeBzYWNaCCDwA X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , Garrett Cooper , Rui Paulo , Gabor Kovesdan , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:35:56 -0000 Quoting Dag-Erling Sm=C3=83=C2=B8rgrav (from Thu, 19 Aug 2010 = =20 11:16:23 +0200): > Alexander Leidinger writes: >> If someone would get icc 11.x up and runnig as a port (similar to what >> we have for outdated icc version in the ports collection), I would >> have a look if my contact at Intel is still working there in a >> position which allows him to get a commercial license for us. > > Does that really matter? We're not going to start building releases > with icc, are we? It could matter for ports, I do not know if it matters for parts in =20 src. The commercial license is also the only way that we could get icc =20 installed on machines in the FreeBSD cluster (if there's interest to =20 have another compiler *for FreeBSD development* to check the source =20 against... the warnng and error messages are better that those of gcc, =20 I do not know how they compare to clang). Bye, Alexander. --=20 Fry: I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 09:39:45 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B29C11065674; Thu, 19 Aug 2010 09:39:45 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 469398FC1D; Thu, 19 Aug 2010 09:39:45 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D177984401F; Thu, 19 Aug 2010 11:39:41 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id AF17E131E; Thu, 19 Aug 2010 11:39:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282210778; bh=+vTgaJp4xziEB4bSjiyQwO6hmT1R/+y5IEOY7cU0Va4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pm0GZ4Q+vMAYdVP759J1faQGjoRwf4E/+V3KvmlnHaZc/VvzjuMPqVlxhZYI+T8xI +Ci/yiUxJe2kgCXSc2rZRelM+FLodb2vUda0lNamphqrwt27bN/o3Rs+IImdxWuLYb PNGneRVxfGX4fBU+ElGarZK7y99Ot+8O4TKHQ1QufpNVfq2ve1baaVT0HWLanVPood 7+fLg9/uy+3FEsnsRcI6+PM2rsNHxNGgR6yuZnpjd+EfkRz9ys++ZigjeIq9ozY0WL WyL6j8w+zbPTYNtQ8Koohejlfk3QuyvDEfvvRvTp2SisbGcN10FjfB/bI8Z6Nk6iWx Cb/xtjpoJV8OQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J9dc8B099808; Thu, 19 Aug 2010 11:39:38 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 11:39:38 +0200 Message-ID: <20100819113938.374618ltvdhg0nok@webmail.leidinger.net> Date: Thu, 19 Aug 2010 11:39:38 +0200 From: Alexander Leidinger To: "V. T. Mueller, Continum" References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <4C6CDB3A.1010200@continum.net> <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> <4C6CF627.20205@continum.net> In-Reply-To: <4C6CF627.20205@continum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D177984401F.A4592 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282815583.37408@LyvHyYbHlLrYG0ujARWH8g X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:39:45 -0000 Quoting "V. T. Mueller, Continum" (from Thu, 19 Aug 2010 11:15:19 +0200): > Alexander Leidinger wrote: >>> Alexander Leidinger wrote: >>>> If someone would get icc 11.x up and runnig as a port (similar to >>>> what we have for outdated icc version in the ports collection), I >>>> would have a look if my contact at Intel is still working there >>>> in a position which allows him to get a commercial license for us. >>> >>> A while ago it was stated by MySQL AB, that their dbms performs >>> about 20% better when compiled with icc instead of gcc. Is this >>> (still) true? >> >> This looks overly simplified. "It runs better on CPU X with >> benchmark Y on Mainboard Z when you use gcc A.B.C with options D >> and compare it to icc E.F.G with options H." is something you can >> use in such cases, but it doesn't tell you if it will be the case >> on your machines with your workload. >> >> If you want to know if it is faster on your machines with your >> workload, then there is only one way to find it out: try it (be >> warned, due to the amount of optimization options available in >> gcc/icc, something like this will take a lot of time, as there are >> a lot of combinations to try). > > Sounds reasonable. But doesn't that mean, that there is no need to > (take the hassle to) support icc in the future? Especially while > folks are being keen on abandon gcc for clang? It may matter in the HPC community where optimization to a specific CPU matters (it doesn't matter that much for MySQL). There it does not matter much to have the kernel compiled with icc, but a icc port would be handy for them. Bye, Alexander. -- I hold it, that a little rebellion, now and then, is a good thing... -- Thomas Jefferson http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 19:15:24 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A20B106566B for ; Thu, 19 Aug 2010 19:15:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 16C398FC08 for ; Thu, 19 Aug 2010 19:15:23 +0000 (UTC) Received: (qmail 7486 invoked by uid 399); 19 Aug 2010 18:48:42 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Aug 2010 18:48:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6D7C89.7040601@FreeBSD.org> Date: Thu, 19 Aug 2010 11:48:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: "arch@freebsd.org" , "current@freebsd.org" References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EDC.5000206@andric.com> <20100819084951.17534pzw4h7ff8kk@webmail.leidinger.net> In-Reply-To: <20100819084951.17534pzw4h7ff8kk@webmail.leidinger.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:15:24 -0000 I think sometimes we act as if code that is removed from the tree is gone forever, with no possibility of it ever returning. I don't understand this attitude. :) If something is unsupported it should be removed, Q.E.D. There is no reason to think of possible reasons that we might want it to stay. Meanwhile, FYI, ports/lang/icc7 has been marked DEPRECATED since 8/8 with removal scheduled for 2010-09-01 based on the distinfo not containing a SHA256 line and (AFAICS) no distfiles available. If and only if someone wants to actively develop a newer version the old port will remain in the repo and can still be used as the basis of a repo copy to a newer version if that is necessary and/or desirable. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-arch@FreeBSD.ORG Thu Aug 19 20:26:50 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9580F1065673; Thu, 19 Aug 2010 20:26:50 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 487C68FC1C; Thu, 19 Aug 2010 20:26:50 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1OmBRR-0006Gw-2L; Thu, 19 Aug 2010 21:10:25 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OmBRQ-0001Ti-Oz; Thu, 19 Aug 2010 21:10:24 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o7JKAOJr020309; Thu, 19 Aug 2010 21:10:24 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o7JKAOuB020308; Thu, 19 Aug 2010 21:10:24 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Thu, 19 Aug 2010 21:10:24 +0100 From: Anton Shterenlikht To: Alexander Leidinger Message-ID: <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> <20100819113548.72614imi2zxx9log@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100819113548.72614imi2zxx9log@webmail.leidinger.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Rui Paulo , "current@freebsd.org" , Garrett Cooper , "arch@freebsd.org" , Gabor Kovesdan , Dag-Erling =?iso-8859-1?Q?Sm=C3=3F=3Frgrav?= Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:26:50 -0000 On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote: > > Quoting Dag-Erling SmÃ??rgrav (from Thu, 19 Aug 2010 > 11:16:23 +0200): > > > Alexander Leidinger writes: > >> If someone would get icc 11.x up and runnig as a port (similar to what > >> we have for outdated icc version in the ports collection), I would > >> have a look if my contact at Intel is still working there in a > >> position which allows him to get a commercial license for us. > > > > Does that really matter? We're not going to start building releases > > with icc, are we? > > It could matter for ports, I do not know if it matters for parts in > src. The commercial license is also the only way that we could get icc > installed on machines in the FreeBSD cluster (if there's interest to > have another compiler *for FreeBSD development* to check the source > against... the warnng and error messages are better that those of gcc, > I do not know how they compare to clang). If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then this becomes a somewhat different discussion. One of the stubmling blocks for HPC on FreeBSD (just one of many, perhaps not even the major one) is a complete lack of good quality commercial compilers. All weÃ'got is gcc or clang. Both are not really that great, and definitely inferior to commercial compilers, e.g. Intel. What IÃ'm saying is that it would be great if Intel sold a compiler for FreeBSD. I'd ve bought a copy. But from what others have said, my impression is that the ICC port is unlikely to fill this void. P.S. My interests and expertise are in computational mechanics, not in compilers, so feel free to correct me if IÃ'm wrong. P.P.S. Regarding FreeBSD HPC see also this thead: http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.html (FreeBSD, GPGPU and OpenCL/CUDA) -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-arch@FreeBSD.ORG Fri Aug 20 01:49:26 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90BD1065702; Fri, 20 Aug 2010 01:49:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF5E8FC14; Fri, 20 Aug 2010 01:49:26 +0000 (UTC) Received: from f8x64.laiers.local (dslb-088-066-061-232.pools.arcor-ip.net [88.66.61.232]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LsdiP-1OsPe92Mm1-012IqZ; Fri, 20 Aug 2010 03:49:25 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Fri, 20 Aug 2010 03:49:23 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <201008160515.21412.max@love2party.net> In-Reply-To: <201008160515.21412.max@love2party.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_j8dbM1irbYuBKIN" Message-Id: <201008200349.23940.max@love2party.net> X-Provags-ID: V02:K0:SzEFDYKkuDHosUPjuY2AsaI3rkiemcnEC0Jdu1C8EtC Fvjx+n0IK99kBWitI9LAEF5d4vFCpAfzdYwhH+HViB/6QS54KK WZMaEeNsSwHVQYsfK4PurXfGBAjhN1qNm/qDOORXLWlANNS9BW Io27buYuhZj57L4BpSAUV61YsgcSbPgayqnT/cxx9w3dKS07HK RiB7erGHNP4vBK94SREVQ== Cc: ups@freebsd.org Subject: Re: rmlock(9) two additions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:49:26 -0000 --Boundary-00=_j8dbM1irbYuBKIN Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi again, On Monday 16 August 2010 05:15:21 I wrote: > I'd like to run two additions to rmlock(9) by you: > > 1) See the attached patch. It adds rm_try_rlock() which avoids taking the > mutex if the lock is currently in a write episode. The only overhead to > the hot path is an additional argument and a return value for _rm_rlock*. > If you are worried about that, it can obviously be done in a separate code > path, but I reckon it not worth the code crunch. Finally, there is one > additional branch to check the "trylock" argument, but that's well past > the hot path. > > 2) No code for this yet - testing the waters first. I'd like to add the > ability to replace the mutex for writer synchronization with a general lock > - especially to be able to use a sx(9) lock here. the attached patch includes code for this as well and updates the man pages accordingly. Instead of using a general lock, I just added a rm_init_flags() flag called "RM_SLEEPABLE" that changes the lock to use an sx(9) lock instead of the mutex. This is enough to support the use case I have in mind. See below for details on that from my original post. There is a bit of "creative" use of witness in this patch, but the result provides proper warnings in all cases. Again: Are there any objections or concerns against this? Otherwise I will commit it soon. Thanks, Max > The reason for #2 is the following use case in a debugging facility: > > "reader": > if (rm_try_rlock()) { > grab_per_cpu_buffer(); > fill_per_cpu_buffer(); > rm_runlock(); > } > > "writer" - better exclusive access thread: > rm_wlock(); > collect_buffers_and_copy_out_to_userspace(); > rm_wunlock(); > > This is much cleaner and possibly cheaper than the various hand rolled > versions I've come across, that try to get the same synchronization with > atomic operations. If we could sleep with the wlock held, we can also > avoid copying the buffer contents, or swapping buffers. --Boundary-00=_j8dbM1irbYuBKIN Content-Type: text/x-patch; charset="ISO-8859-1"; name="rmlock.try_and_sleep.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rmlock.try_and_sleep.diff" diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile index f8dec17..f05c4c6 100644 --- a/share/man/man9/Makefile +++ b/share/man/man9/Makefile @@ -985,6 +985,7 @@ MLINKS+=rman.9 rman_activate_resource.9 \ MLINKS+=rmlock.9 rm_destroy.9 \ rmlock.9 rm_init.9 \ rmlock.9 rm_rlock.9 \ + rmlock.9 rm_try_rlock.9 \ rmlock.9 rm_runlock.9 \ rmlock.9 RM_SYSINIT.9 \ rmlock.9 rm_wlock.9 \ diff --git a/share/man/man9/locking.9 b/share/man/man9/locking.9 index 005f476..3728319 100644 --- a/share/man/man9/locking.9 +++ b/share/man/man9/locking.9 @@ -301,7 +301,7 @@ one of the synchronization primitives discussed: .It mutex Ta \&ok Ta \&ok-1 Ta \&no Ta \&ok Ta \&ok Ta \&no-3 .It sx Ta \&ok Ta \&ok Ta \&ok-2 Ta \&ok Ta \&ok Ta \&ok-4 .It rwlock Ta \&ok Ta \&ok Ta \&no Ta \&ok-2 Ta \&ok Ta \&no-3 -.It rmlock Ta \&ok Ta \&ok Ta \&no Ta \&ok Ta \&ok-2 Ta \&no +.It rmlock Ta \&ok Ta \&ok Ta \&ok-5 Ta \&ok Ta \&ok-2 Ta \&ok-5 .El .Pp .Em *1 @@ -326,6 +326,13 @@ Though one can sleep holding an sx lock, one can also use .Fn sx_sleep which will atomically release this primitive when going to sleep and reacquire it on wakeup. +.Pp +.Em *5 +.Em Read-mostly +locks can be initialized to support sleeping while holding a write lock. +See +.Xr rmlock 9 +for details. .Ss Context mode table The next table shows what can be used in different contexts. At this time this is a rather easy to remember table. diff --git a/share/man/man9/rmlock.9 b/share/man/man9/rmlock.9 index e99661d..28ac0a5 100644 --- a/share/man/man9/rmlock.9 +++ b/share/man/man9/rmlock.9 @@ -35,6 +35,7 @@ .Nm rm_init_flags , .Nm rm_destroy , .Nm rm_rlock , +.Nm rm_try_rlock , .Nm rm_wlock , .Nm rm_runlock , .Nm rm_wunlock , @@ -53,6 +54,8 @@ .Fn rm_destroy "struct rmlock *rm" .Ft void .Fn rm_rlock "struct rmlock *rm" "struct rm_priotracker* tracker" +.Ft int +.Fn rm_try_rlock "struct rmlock *rm" "struct rm_priotracker* tracker" .Ft void .Fn rm_wlock "struct rmlock *rm" .Ft void @@ -84,14 +87,16 @@ Although reader/writer locks look very similar to locks, their usage pattern is different. Reader/writer locks can be treated as mutexes (see .Xr mutex 9 ) -with shared/exclusive semantics. +with shared/exclusive semantics unless initialized with +.Dv RM_SLEEPABLE . Unlike .Xr sx 9 , an .Nm can be locked while holding a non-spin mutex, and an .Nm -cannot be held while sleeping. +cannot be held while sleeping, again unless initialized with +.Dv RM_SLEEPABLE . The .Nm locks have full priority propagation like mutexes. @@ -135,6 +140,13 @@ to ignore this lock. .It Dv RM_RECURSE Allow threads to recursively acquire exclusive locks for .Fa rm . +.It Dv RM_SLEEPABLE +Allow writers to sleep while holding the lock. +Readers must not sleep while holding the lock and can avoid to sleep on +taking the lock by using +.Fn rm_try_rlock +instead of +.Fn rm_rlock . .El .It Fn rm_rlock "struct rmlock *rm" "struct rm_priotracker* tracker" Lock @@ -161,6 +173,13 @@ access on .Fa rm . This is called .Dq "recursing on a lock" . +.It Fn rm_try_rlock "struct rmlock *rm" "struct rm_priotracker* tracker" +Try to lock +.Fa rm +as a reader. +.Fn rm_try_rlock +will return 0 if the lock cannot be acquired immediately; +otherwise the lock will be acquired and a non-zero value will be returned. .It Fn rm_wlock "struct rmlock *rm" Lock .Fa rm diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c index a6a622e..c1aca1d 100644 --- a/sys/kern/kern_rmlock.c +++ b/sys/kern/kern_rmlock.c @@ -187,6 +187,8 @@ rm_cleanIPI(void *arg) } } +CTASSERT((RM_SLEEPABLE & LO_CLASSFLAGS) == RM_SLEEPABLE); + void rm_init_flags(struct rmlock *rm, const char *name, int opts) { @@ -199,7 +201,11 @@ rm_init_flags(struct rmlock *rm, const char *name, int opts) liflags |= LO_RECURSABLE; rm->rm_noreadtoken = 1; LIST_INIT(&rm->rm_activeReaders); - mtx_init(&rm->rm_lock, name, "rmlock_mtx", MTX_NOWITNESS); + if (opts & RM_SLEEPABLE) { + liflags |= RM_SLEEPABLE; + sx_init_flags(&rm->rm_lock_sx, "rmlock_sx", SX_RECURSE); + } else + mtx_init(&rm->rm_lock_mtx, name, "rmlock_mtx", MTX_NOWITNESS); lock_init(&rm->lock_object, &lock_class_rm, name, NULL, liflags); } @@ -214,7 +220,10 @@ void rm_destroy(struct rmlock *rm) { - mtx_destroy(&rm->rm_lock); + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + sx_destroy(&rm->rm_lock_sx); + else + mtx_destroy(&rm->rm_lock_mtx); lock_destroy(&rm->lock_object); } @@ -222,7 +231,10 @@ int rm_wowned(struct rmlock *rm) { - return (mtx_owned(&rm->rm_lock)); + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + return (sx_xlocked(&rm->rm_lock_sx)); + else + return (mtx_owned(&rm->rm_lock_mtx)); } void @@ -241,8 +253,8 @@ rm_sysinit_flags(void *arg) rm_init_flags(args->ra_rm, args->ra_desc, args->ra_opts); } -static void -_rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) +static int +_rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) { struct pcpu *pc; struct rm_queue *queue; @@ -254,7 +266,7 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) /* Check if we just need to do a proper critical_exit. */ if (0 == rm->rm_noreadtoken) { critical_exit(); - return; + return (1); } /* Remove our tracker from the per-cpu list. */ @@ -265,7 +277,7 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) /* Just add back tracker - we hold the lock. */ rm_tracker_add(pc, tracker); critical_exit(); - return; + return (1); } /* @@ -289,7 +301,7 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) mtx_unlock_spin(&rm_spinlock); rm_tracker_add(pc, tracker); critical_exit(); - return; + return (1); } } } @@ -297,7 +309,13 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) sched_unpin(); critical_exit(); - mtx_lock(&rm->rm_lock); + if (trylock) + return (0); + + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + sx_xlock(&rm->rm_lock_sx); + else + mtx_lock(&rm->rm_lock_mtx); rm->rm_noreadtoken = 0; critical_enter(); @@ -306,11 +324,16 @@ _rm_rlock_hard(struct rmlock *rm, struct rm_priotracker *tracker) sched_pin(); critical_exit(); - mtx_unlock(&rm->rm_lock); + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + sx_xunlock(&rm->rm_lock_sx); + else + mtx_unlock(&rm->rm_lock_mtx); + + return (1); } -void -_rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker) +int +_rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) { struct thread *td = curthread; struct pcpu *pc; @@ -338,10 +361,10 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker) * conditional jump. */ if (0 == (td->td_owepreempt | rm->rm_noreadtoken)) - return; + return (1); /* We do not have a read token and need to acquire one. */ - _rm_rlock_hard(rm, tracker); + return _rm_rlock_hard(rm, tracker, trylock); } static void @@ -401,7 +424,10 @@ _rm_wlock(struct rmlock *rm) struct rm_priotracker *prio; struct turnstile *ts; - mtx_lock(&rm->rm_lock); + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + sx_xlock(&rm->rm_lock_sx); + else + mtx_lock(&rm->rm_lock_mtx); if (rm->rm_noreadtoken == 0) { /* Get all read tokens back */ @@ -439,7 +465,10 @@ void _rm_wunlock(struct rmlock *rm) { - mtx_unlock(&rm->rm_lock); + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + sx_xunlock(&rm->rm_lock_sx); + else + mtx_unlock(&rm->rm_lock_mtx); } #ifdef LOCK_DEBUG @@ -454,7 +483,11 @@ void _rm_wlock_debug(struct rmlock *rm, const char *file, int line) LOCK_LOG_LOCK("RMWLOCK", &rm->lock_object, 0, 0, file, line); - WITNESS_LOCK(&rm->lock_object, LOP_EXCLUSIVE, file, line); + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + WITNESS_LOCK(&rm->rm_lock_sx.lock_object, LOP_EXCLUSIVE, + file, line); + else + WITNESS_LOCK(&rm->lock_object, LOP_EXCLUSIVE, file, line); curthread->td_locks++; @@ -465,25 +498,35 @@ _rm_wunlock_debug(struct rmlock *rm, const char *file, int line) { curthread->td_locks--; - WITNESS_UNLOCK(&rm->lock_object, LOP_EXCLUSIVE, file, line); + if (rm->lock_object.lo_flags & RM_SLEEPABLE) + WITNESS_UNLOCK(&rm->rm_lock_sx.lock_object, LOP_EXCLUSIVE, + file, line); + else + WITNESS_UNLOCK(&rm->lock_object, LOP_EXCLUSIVE, file, line); LOCK_LOG_LOCK("RMWUNLOCK", &rm->lock_object, 0, 0, file, line); _rm_wunlock(rm); } -void +int _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, - const char *file, int line) + int trylock, const char *file, int line) { - + if (!trylock && (rm->lock_object.lo_flags & RM_SLEEPABLE)) + WITNESS_CHECKORDER(&rm->rm_lock_sx.lock_object, LOP_NEWORDER, + file, line, NULL); WITNESS_CHECKORDER(&rm->lock_object, LOP_NEWORDER, file, line, NULL); - _rm_rlock(rm, tracker); + if (_rm_rlock(rm, tracker, trylock)) { + LOCK_LOG_LOCK("RMRLOCK", &rm->lock_object, 0, 0, file, line); - LOCK_LOG_LOCK("RMRLOCK", &rm->lock_object, 0, 0, file, line); + WITNESS_LOCK(&rm->lock_object, 0, file, line); - WITNESS_LOCK(&rm->lock_object, 0, file, line); + curthread->td_locks++; - curthread->td_locks++; + return (1); + } + + return (0); } void @@ -517,12 +560,12 @@ _rm_wunlock_debug(struct rmlock *rm, const char *file, int line) _rm_wunlock(rm); } -void +int _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, - const char *file, int line) + int trylock, const char *file, int line) { - _rm_rlock(rm, tracker); + return _rm_rlock(rm, tracker, trylock); } void diff --git a/sys/sys/_rmlock.h b/sys/sys/_rmlock.h index e5c68d5..5fb4447 100644 --- a/sys/sys/_rmlock.h +++ b/sys/sys/_rmlock.h @@ -47,9 +47,13 @@ struct rmlock { struct lock_object lock_object; volatile int rm_noreadtoken; LIST_HEAD(,rm_priotracker) rm_activeReaders; - struct mtx rm_lock; - + union { + struct mtx _rm_lock_mtx; + struct sx _rm_lock_sx; + } _rm_lock; }; +#define rm_lock_mtx _rm_lock._rm_lock_mtx +#define rm_lock_sx _rm_lock._rm_lock_sx struct rm_priotracker { struct rm_queue rmp_cpuQueue; /* Must be first */ diff --git a/sys/sys/rmlock.h b/sys/sys/rmlock.h index 9766f67..ef5776b 100644 --- a/sys/sys/rmlock.h +++ b/sys/sys/rmlock.h @@ -33,6 +33,7 @@ #define _SYS_RMLOCK_H_ #include +#include #include #include @@ -43,6 +44,7 @@ */ #define RM_NOWITNESS 0x00000001 #define RM_RECURSE 0x00000002 +#define RM_SLEEPABLE 0x00000004 void rm_init(struct rmlock *rm, const char *name); void rm_init_flags(struct rmlock *rm, const char *name, int opts); @@ -53,14 +55,15 @@ void rm_sysinit_flags(void *arg); void _rm_wlock_debug(struct rmlock *rm, const char *file, int line); void _rm_wunlock_debug(struct rmlock *rm, const char *file, int line); -void _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, - const char *file, int line); +int _rm_rlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, + int trylock, const char *file, int line); void _rm_runlock_debug(struct rmlock *rm, struct rm_priotracker *tracker, const char *file, int line); void _rm_wlock(struct rmlock *rm); void _rm_wunlock(struct rmlock *rm); -void _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker); +int _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, + int trylock); void _rm_runlock(struct rmlock *rm, struct rm_priotracker *tracker); /* @@ -74,14 +77,17 @@ void _rm_runlock(struct rmlock *rm, struct rm_priotracker *tracker); #define rm_wlock(rm) _rm_wlock_debug((rm), LOCK_FILE, LOCK_LINE) #define rm_wunlock(rm) _rm_wunlock_debug((rm), LOCK_FILE, LOCK_LINE) #define rm_rlock(rm,tracker) \ - _rm_rlock_debug((rm),(tracker), LOCK_FILE, LOCK_LINE ) + ((void)_rm_rlock_debug((rm),(tracker), 0, LOCK_FILE, LOCK_LINE )) +#define rm_try_rlock(rm,tracker) \ + _rm_rlock_debug((rm),(tracker), 1, LOCK_FILE, LOCK_LINE ) #define rm_runlock(rm,tracker) \ _rm_runlock_debug((rm), (tracker), LOCK_FILE, LOCK_LINE ) #else -#define rm_wlock(rm) _rm_wlock((rm)) -#define rm_wunlock(rm) _rm_wunlock((rm)) -#define rm_rlock(rm,tracker) _rm_rlock((rm),(tracker)) -#define rm_runlock(rm,tracker) _rm_runlock((rm), (tracker)) +#define rm_wlock(rm) _rm_wlock((rm)) +#define rm_wunlock(rm) _rm_wunlock((rm)) +#define rm_rlock(rm,tracker) ((void)_rm_rlock((rm),(tracker), 0)) +#define rm_try_rlock(rm,tracker) _rm_rlock((rm),(tracker), 1) +#define rm_runlock(rm,tracker) _rm_runlock((rm), (tracker)) #endif struct rm_args { --Boundary-00=_j8dbM1irbYuBKIN-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 20 09:05:28 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 244DA10656A4; Fri, 20 Aug 2010 09:05:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CFEBC8FC13; Fri, 20 Aug 2010 09:05:27 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DDB6D1FFC34; Fri, 20 Aug 2010 09:05:25 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B7FC18456E; Fri, 20 Aug 2010 11:05:25 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Anton Shterenlikht References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> <20100819113548.72614imi2zxx9log@webmail.leidinger.net> <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> Date: Fri, 20 Aug 2010 11:05:25 +0200 In-Reply-To: <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> (Anton Shterenlikht's message of "Thu, 19 Aug 2010 21:10:24 +0100") Message-ID: <86d3tdy7qi.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Rui Paulo , "current@freebsd.org" , Garrett Cooper , "arch@freebsd.org" , Gabor Kovesdan , Alexander Leidinger Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:05:28 -0000 Anton Shterenlikht writes: >> It could matter for ports, I do not know if it matters for parts in=20=20 >> src. The commercial license is also the only way that we could get icc= =20=20 >> installed on machines in the FreeBSD cluster [...] > If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, Not "FreeBSD clusters", but "*the* FreeBSD cluster", i.e. the .f.o machines hosted by Y!. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Aug 21 21:45:33 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B19F10656A4 for ; Sat, 21 Aug 2010 21:45:33 +0000 (UTC) (envelope-from ups@freebsd.org) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by mx1.freebsd.org (Postfix) with SMTP id AA1798FC15 for ; Sat, 21 Aug 2010 21:45:31 +0000 (UTC) Received: (qmail 12275 invoked from network); 21 Aug 2010 21:18:51 -0000 Received: from unknown (75.139.142.171) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 21 Aug 2010 21:18:51 -0000 Message-ID: <4C7042BA.8000402@freebsd.org> Date: Sat, 21 Aug 2010 17:18:50 -0400 From: Stephan Uphoff User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Max Laier References: <201008160515.21412.max@love2party.net> In-Reply-To: <201008160515.21412.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: rmlock(9) two additions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 21:45:33 -0000 Max Laier wrote: > Hi, > > I'd like to run two additions to rmlock(9) by you: > > 1) See the attached patch. It adds rm_try_rlock() which avoids taking the > mutex if the lock is currently in a write episode. The only overhead to the > hot path is an additional argument and a return value for _rm_rlock*. If you > are worried about that, it can obviously be done in a separate code path, but > I reckon it not worth the code crunch. Finally, there is one additional > branch to check the "trylock" argument, but that's well past the hot path. > The rm_try_rlock() will never succeed when the lock was last locked as writer. Maybe add: void _rm_wunlock(struct rmlock *rm) { + rm->rm_noreadtoken = 0; mtx_unlock(&rm->rm_lock); } But then _rm_wlock(struct rmlock *rm) always needs to use IPIs - even when the lock was used last as a write lock. Alternatively something like: if (trylock) { if(mtx_trylock( &rm->rm_lock) == 0) return (0); } else { mtx_lock(&rm->rm_lock); } would work - but has a race. Two readers colliding just after a writer (with the second not succeeding in trylocking the mutex) leads to not granting the read lock (also it would be possible to do so). Let me think about it a bit. > 2) No code for this yet - testing the waters first. I'd like to add the > ability to replace the mutex for writer synchronization with a general lock - > especially to be able to use a sx(9) lock here. > > The reason for #2 is the following use case in a debugging facility: > > "reader": > if (rm_try_rlock()) { > grab_per_cpu_buffer(); > fill_per_cpu_buffer(); > rm_runlock(); > } > > "writer" - better exclusive access thread: > rm_wlock(); > collect_buffers_and_copy_out_to_userspace(); > rm_wunlock(); > > This is much cleaner and possibly cheaper than the various hand rolled > versions I've come across, that try to get the same synchronization with > atomic operations. If we could sleep with the wlock held, we can also avoid > copying the buffer contents, or swapping buffers. > > Is there any concern about either of this? Any objection? Input? > > Will take a look at your second patch soonish. Just ask per IPI for a copy of per cpu buffers (but not a copy to user space) - and delay the copy when an update is in progress? Stephan > Thanks, > Max Laier >