From owner-freebsd-arch@FreeBSD.ORG Sun Sep 5 23:34:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4900E16A4CE for ; Sun, 5 Sep 2004 23:34:46 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6FB43D2D for ; Sun, 5 Sep 2004 23:34:45 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i85NVwpc011773; Sun, 5 Sep 2004 19:31:58 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i85NVs8O011770; Sun, 5 Sep 2004 19:31:58 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 5 Sep 2004 19:31:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Paul Smith In-Reply-To: <200409042056.i84Kudsk021327@cello.qnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Microkernel Performance: FreeBSD versus Darwin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2004 23:34:46 -0000 On Sat, 4 Sep 2004, Paul Smith wrote: > Theoretically the microkernel of Darwin should create overheads harming > the performance. Has anybody seen an actual study comparing the > performance of Darwin and FreeBSD? FYI, Darwin doesn't use a microkernel. It includes code elements from Mach, which did use a microkernel, but those elements are integrated into the same address space as the remainder of the kernel (file system, network stack, etc). I'm not sure I've seen any performance studies, regardless. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 01:21:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82D8D16A4CE for ; Mon, 6 Sep 2004 01:21:55 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBA9C43D1D for ; Mon, 6 Sep 2004 01:21:54 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 61B9850C00 for ; Mon, 6 Sep 2004 10:21:53 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id C49DC50C1A for ; Mon, 6 Sep 2004 10:21:51 +0900 (JST) Date: Mon, 06 Sep 2004 10:21:51 +0900 Message-ID: <7msm9wur80.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: arch@FreeBSD.org In-Reply-To: <20040904051330.GH45292@green.homeunix.org> References: <7m3c20x7p3.wl@black.imgsrc.co.jp> <20040904051330.GH45292@green.homeunix.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: Re: abort(3) in libc/db/btree/bt_split.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 01:21:55 -0000 At Sat, 4 Sep 2004 01:13:30 -0400, Brian Fundakowski Feldman wrote: > Have you checked if they were fixed in subsequent SleepyCat DB 1.x > releases to return error instead of dump core, so we could use a vendor > fix? Unfortunatelly, I checked their 1.86 distribution, but there is no changes in this area. -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 05:04:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56AA816A4CE for ; Mon, 6 Sep 2004 05:04:37 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA24443D54 for ; Mon, 6 Sep 2004 05:04:36 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 17636 invoked from network); 6 Sep 2004 05:04:36 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Sep 2004 05:04:36 -0000 Received: from hydrogen.funkthat.com (bixsto@localhost.funkthat.com [127.0.0.1])i8654ZuU072384; Sun, 5 Sep 2004 22:04:36 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8654ZQZ072383; Sun, 5 Sep 2004 22:04:35 -0700 (PDT) Date: Sun, 5 Sep 2004 22:04:35 -0700 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Message-ID: <20040906050435.GA72089@funkthat.com> Mail-Followup-To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: better MTU support... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 05:04:37 -0000 In a recent experiment w/ Jumbo frames, I found out that sending ip frames completely ignores the MTU set on host routes. This makes it difficult (or next to impossible) to support a network that has both regular and jumbo frames on it as you can't restrict some hosts to the smaller frames. I now have a patch to ip_output that makes it obay the MTU set on the route instead of that of the interface. Please review: http://people.FreeBSD.org/~jmg/ip_mtu.diff Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 08:47:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E08F16A4CE; Mon, 6 Sep 2004 08:47:28 +0000 (GMT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CB0B43D48; Mon, 6 Sep 2004 08:47:27 +0000 (GMT) SRS0+3b5aba12a0c273db2f6f+379+infradead.org+hch@phoenix.srs.infradead.org) Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1C4F9p-000173-32; Mon, 06 Sep 2004 09:47:25 +0100 Date: Mon, 6 Sep 2004 09:47:24 +0100 From: Christoph Hellwig To: Robert Watson Message-ID: <20040906094724.A4262@infradead.org> References: <200409042056.i84Kudsk021327@cello.qnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rwatson@freebsd.org on Sun, Sep 05, 2004 at 07:31:54PM -0400 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html cc: Paul Smith cc: freebsd-arch@freebsd.org Subject: Re: Microkernel Performance: FreeBSD versus Darwin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 08:47:28 -0000 On Sun, Sep 05, 2004 at 07:31:54PM -0400, Robert Watson wrote: > > On Sat, 4 Sep 2004, Paul Smith wrote: > > > Theoretically the microkernel of Darwin should create overheads harming > > the performance. Has anybody seen an actual study comparing the > > performance of Darwin and FreeBSD? > > FYI, Darwin doesn't use a microkernel. It includes code elements from > Mach, which did use a microkernel, but those elements are integrated into > the same address space as the remainder of the kernel (file system, > network stack, etc). I'm not sure I've seen any performance studies, > regardless. http://www-106.ibm.com/developerworks/linux/library/l-ydlg5.html?ca=dgr-mw05LinxOnG5 has some microbenchmarks for darwin vs linux From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 09:35:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B35C16A4D0 for ; Mon, 6 Sep 2004 09:35:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A714143D2D for ; Mon, 6 Sep 2004 09:35:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 8C1A01FFDD8; Mon, 6 Sep 2004 11:35:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 9D20A1FFDD6; Mon, 6 Sep 2004 11:35:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id A9E731567C; Mon, 6 Sep 2004 09:32:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9F24115672; Mon, 6 Sep 2004 09:32:06 +0000 (UTC) Date: Mon, 6 Sep 2004 09:32:06 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Scott Long In-Reply-To: <4135118A.5030807@samsco.org> Message-ID: References: <4134DF35.7070605@freebsd.org><4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> <4134FF74.4010105@freebsd.org> <4135051E.2070007@elischer.org> <4135118A.5030807@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-arch@freebsd.org Subject: Re: netgraph locking / performance [was: ... AOE] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 09:35:10 -0000 On Tue, 31 Aug 2004, Scott Long wrote: Hi, > My employer has done extensive profiling of packet delivery through > netgraph. While the locking of the netgraph framework is definitely > correct, it's not terribly efficient and leads to a good deal of > latency. We are looking at various proposals on how to address this. > This isn't a criticism of you or Netgraph, just a set 'real-life' > observations under very high load (bridging and packet inspection on > 4 GigE links simultaneously qualifies as high load =-) could please explain a bit more / give some numbers ? Or are there any published results ? What do you mean by 'packet inspection' ? And what hardware did you use to fill up 4GigE pipes ? -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 09:45:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3007916A4CE for ; Mon, 6 Sep 2004 09:45:38 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68EBD43D6D for ; Mon, 6 Sep 2004 09:45:37 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i869jL2362950; Mon, 6 Sep 2004 11:45:21 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i869jKI109740; Mon, 6 Sep 2004 11:45:20 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i869j5e21175; Mon, 6 Sep 2004 11:45:15 +0200 (MET DST) Date: Mon, 6 Sep 2004 11:45:06 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: "Bjoern A. Zeeb" In-Reply-To: Message-ID: <20040906113737.X16723@beagle.kn.op.dlr.de> References: <4134DF35.7070605@freebsd.org><4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> <4134FF74.4010105@freebsd.org> <4135051E.2070007@elischer.org> <4135118A.5030807@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: netgraph locking / performance [was: ... AOE] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 09:45:38 -0000 On Mon, 6 Sep 2004, Bjoern A. Zeeb wrote: BAZ>On Tue, 31 Aug 2004, Scott Long wrote: BAZ> BAZ>Hi, BAZ> BAZ>> My employer has done extensive profiling of packet delivery through BAZ>> netgraph. While the locking of the netgraph framework is definitely BAZ>> correct, it's not terribly efficient and leads to a good deal of BAZ>> latency. We are looking at various proposals on how to address this. BAZ>> This isn't a criticism of you or Netgraph, just a set 'real-life' BAZ>> observations under very high load (bridging and packet inspection on BAZ>> 4 GigE links simultaneously qualifies as high load =-) BAZ> BAZ>could please explain a bit more / give some numbers ? Or are there BAZ>any published results ? What do you mean by 'packet inspection' ? That would also interest me. I did measurements with my satellite link simulator (a netgraph node) and got a couple of 100usec latency when pushing 150k ATM cells through the node (each cell counting as a packet). including the processing of the two ATM adapters. Does this already count as high latency? harti From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 10:45:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 044FC16A4CE for ; Mon, 6 Sep 2004 10:45:32 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6100143D2D for ; Mon, 6 Sep 2004 10:45:31 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i86AjT46046740 for ; Mon, 6 Sep 2004 12:45:29 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Mon, 06 Sep 2004 12:45:29 +0200 Message-ID: <46739.1094467529@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Thoughts about malloc(3) and threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 10:45:32 -0000 A number of times the issue of memory allocation in threaded programs have come up in various fora. In order to not become a road block for this important area, I want to state my opinion on this matter for the record: For single-threaded programs and non-malloc intensive multi-threaded programs I am still of the opinion that phkmalloc is our best choice. The combination of strong error checking and focus on minimal working set size seems to me a good compromise between functionality and raw performance for a general purpose malloc in a general purpose operating system. For multi-threaded programs with a lot of malloc activity, phkmalloc does not work well since it requires one big lock around the entire thing and does not do anything to preserve processor affinity. I think we need a malloc which can service this hi-end segment effectively, but even though various suggestions for replacements of phkmalloc to address this have been made, I do not see any clear winner or even the full list of candidates yet. Since a malloc which is aware of multiple CPUs or which relies on per-cpu locks can not implement a strong level of error checking, my guess is that we will end up retaining phkmalloc as the default and have a "SMP malloc" for the heavy duty case. It can (and without doubt will) be argued that the "SMP malloc" should be a port, but lets not even go there until we have a candidate. So, short version of my position is: I am not and will not be researching this topic and that people with a serious interest in it should get started. Given the list of programs which have been found buggy by phkmalloc, I do not think we should default to a malloc which does not have strong error checking. If a malloc better than phkmalloc in performance and error checking is found/written, I'll be all for a replacement if that means we will only have one malloc. Anyone wanting to work on this is welcome to contact me for some hard-earned insight into what and how to benchmark etc. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 11:19:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAAD316A4CE for ; Mon, 6 Sep 2004 11:19:23 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D48543D5E for ; Mon, 6 Sep 2004 11:19:23 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id E6E6D443C; Mon, 6 Sep 2004 13:19:59 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 38702B85E; Mon, 6 Sep 2004 13:19:22 +0200 (CEST) To: Poul-Henning Kamp References: <46739.1094467529@critter.freebsd.dk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 06 Sep 2004 13:19:22 +0200 In-Reply-To: <46739.1094467529@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 06 Sep 2004 12:45:29 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: Thoughts about malloc(3) and threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 11:19:24 -0000 Poul-Henning Kamp writes: > So, short version of my position is: > [...] you forgot the most important part: "no matter how hard you think it will be to write a good paralell allocator, it will be harder than you think" DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 11:31:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7B1916A4CE for ; Mon, 6 Sep 2004 11:31:59 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2023B43D41 for ; Mon, 6 Sep 2004 11:31:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i86BVvFI047445; Mon, 6 Sep 2004 13:31:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 06 Sep 2004 13:19:22 +0200." Date: Mon, 06 Sep 2004 13:31:57 +0200 Message-ID: <47444.1094470317@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: Thoughts about malloc(3) and threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 11:31:59 -0000 In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >Poul-Henning Kamp writes: >> So, short version of my position is: >> [...] > >you forgot the most important part: > >"no matter how hard you think it will be to write a good paralell >allocator, it will be harder than you think" Shhhh! you shouldn't have told them that yet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 22:13:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86AB716A4CE for ; Mon, 6 Sep 2004 22:13:34 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B83D343D3F for ; Mon, 6 Sep 2004 22:13:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i86MBHpt029719 for ; Mon, 6 Sep 2004 16:11:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 06 Sep 2004 16:11:43 -0600 (MDT) Message-Id: <20040906.161143.77047315.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Sep__6_16:11:43_2004_055)--" Content-Transfer-Encoding: 7bit Subject: Change to output X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 22:13:34 -0000 ----Next_Part(Mon_Sep__6_16:11:43_2004_055)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Consider the following patch. It includes the target being built as well as the subdir in output for subdirectory recursion. For small projects, I'm sure that the current way of dealing is sufficent, but it is hard to know what's going on in the middle of makeworld, and this helps. Here's some sample output from a world I'm running: ===> usr.sbin/zic (obj) ===> usr.sbin/zic/zic (obj) ===> usr.sbin/zic/zdump (obj) ===> usr.sbin/zzz (obj) -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- ===> bin/csh (obj,build-tools) ===> bin/sh (obj,build-tools) ===> rescue/rescue (obj,build-tools) ===> rescue/rescue/rtquery (obj) ===> rescue/rescue/common (obj) ===> rescue/rescue/dst (obj) ===> rescue/rescue/minires (obj) ===> rescue/rescue/omapip (obj) ===> rescue/rescue/dhcpctl (obj) ===> rescue/rescue/client (obj) ===> rescue/rescue/omshell (obj) ===> rescue/rescue/doc (obj) ===> rescue/rescue/doc (obj) ===> lib/libncurses (obj,build-tools) ===> share/syscons/scrnmaps (obj,build-tools) ===> usr.bin/awk (obj,build-tools) ===> lib/libmagic (obj,build-tools) ===> usr.sbin/sysinstall (obj,build-tools) ===> gnu/usr.bin/cc/cc_tools (obj,depend,all) ===> kerberos5/tools (obj,depend,all) ===> kerberos5/tools/make-print-version (obj) ===> kerberos5/tools/make-roken (obj) ===> kerberos5/tools/asn1_compile (obj) ===> kerberos5/tools/make-print-version (depend) ===> kerberos5/tools/make-roken (depend) ===> kerberos5/tools/asn1_compile (depend) ===> kerberos5/tools/make-print-version (all) ===> kerberos5/tools/make-roken (all) ===> kerberos5/tools/asn1_compile (all) notice how it explains nicely why it appears that asn1_compile is built 3 times (it really isn't, but you have to do the obj, depend and all parts). I've been running these patches, or variations on the theme for over two years now. I'm thinking it would be good to commit to head. Comments? Warner ----Next_Part(Mon_Sep__6_16:11:43_2004_055)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mk.diff" Index: Makefile.inc1 =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/Makefile.inc1,v retrieving revision 1.443 diff -u -r1.443 Makefile.inc1 --- Makefile.inc1 26 Aug 2004 10:24:25 -0000 1.443 +++ Makefile.inc1 6 Sep 2004 16:40:18 -0000 @@ -675,7 +675,7 @@ # legacy: .for _tool in tools/build - ${_+_}@${ECHODIR} "===> ${_tool}"; \ + ${_+_}@${ECHODIR} "===> ${_tool} (obj,includes,depend,all,install)"; \ cd ${.CURDIR}/${_tool}; \ ${MAKE} DIRPRFX=${_tool}/ obj; \ ${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX}/legacy includes; \ @@ -750,7 +750,7 @@ ${_crunchgen} \ ${_gensnmptree} \ ${_kbdcontrol} - ${_+_}@${ECHODIR} "===> ${_tool}"; \ + ${_+_}@${ECHODIR} "===> ${_tool} (obj,depend,all,install)"; \ cd ${.CURDIR}/${_tool}; \ ${MAKE} DIRPRFX=${_tool}/ obj; \ ${MAKE} DIRPRFX=${_tool}/ depend; \ @@ -788,7 +788,7 @@ usr.bin/awk \ lib/libmagic \ usr.sbin/sysinstall - ${_+_}@${ECHODIR} "===> ${_tool}"; \ + ${_+_}@${ECHODIR} "===> ${_tool} (obj,build-tools)"; \ cd ${.CURDIR}/${_tool}; \ ${MAKE} DIRPRFX=${_tool}/ obj; \ ${MAKE} DIRPRFX=${_tool}/ build-tools @@ -796,7 +796,7 @@ .for _tool in \ gnu/usr.bin/cc/cc_tools \ ${_kerberos5_tools} - ${_+_}@${ECHODIR} "===> ${_tool}"; \ + ${_+_}@${ECHODIR} "===> ${_tool} (obj,depend,all)"; \ cd ${.CURDIR}/${_tool}; \ ${MAKE} DIRPRFX=${_tool}/ obj; \ ${MAKE} DIRPRFX=${_tool}/ depend; \ @@ -840,7 +840,7 @@ ${_crunchide} \ ${_elf2exe} \ ${_kgzip} - ${_+_}@${ECHODIR} "===> ${_tool}"; \ + ${_+_}@${ECHODIR} "===> ${_tool} (obj,depend,all,install)"; \ cd ${.CURDIR}/${_tool}; \ ${MAKE} DIRPRFX=${_tool}/ obj; \ ${MAKE} DIRPRFX=${_tool}/ depend; \ @@ -933,7 +933,7 @@ .for _lib in ${_startup_libs} ${_prebuild_libs:Nlib/libpam} ${_generic_libs} ${_lib}__L: .PHONY .if exists(${.CURDIR}/${_lib}) - ${_+_}@${ECHODIR} "===> ${_lib}"; \ + ${_+_}@${ECHODIR} "===> ${_lib} (depend,all,install)"; \ cd ${.CURDIR}/${_lib}; \ ${MAKE} DIRPRFX=${_lib}/ depend; \ ${MAKE} DIRPRFX=${_lib}/ all; \ @@ -945,7 +945,7 @@ # static PAM library, and dynamic PAM library before dynamic PAM # modules. lib/libpam__L: .PHONY - ${_+_}@${ECHODIR} "===> lib/libpam"; \ + ${_+_}@${ECHODIR} "===> lib/libpam (depend,all,install)"; \ cd ${.CURDIR}/lib/libpam; \ ${MAKE} DIRPRFX=lib/libpam/ depend; \ ${MAKE} DIRPRFX=lib/libpam/ -D_NO_LIBPAM_SO_YET all; \ @@ -959,11 +959,11 @@ .for entry in ${SUBDIR} ${entry}.${__target}__D: .PHONY ${_+_}@if test -d ${.CURDIR}/${entry}.${MACHINE_ARCH}; then \ - ${ECHODIR} "===> ${DIRPRFX}${entry}.${MACHINE_ARCH}"; \ + ${ECHODIR} "===> ${DIRPRFX}${entry}.${MACHINE_ARCH} (${__target})"; \ edir=${entry}.${MACHINE_ARCH}; \ cd ${.CURDIR}/$${edir}; \ else \ - ${ECHODIR} "===> ${DIRPRFX}${entry}"; \ + ${ECHODIR} "===> ${DIRPRFX}${entry} (${__target})"; \ edir=${entry}; \ cd ${.CURDIR}/$${edir}; \ fi; \ Index: share/mk/bsd.subdir.mk =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/share/mk/bsd.subdir.mk,v retrieving revision 1.45 diff -u -r1.45 bsd.subdir.mk --- share/mk/bsd.subdir.mk 9 Aug 2004 10:54:05 -0000 1.45 +++ share/mk/bsd.subdir.mk 6 Sep 2004 16:25:36 -0000 @@ -44,11 +44,11 @@ .if defined(SUBDIR) && !empty(SUBDIR) && !defined(NO_SUBDIR) @${_+_}for entry in ${SUBDIR}; do \ if test -d ${.CURDIR}/$${entry}.${MACHINE_ARCH}; then \ - ${ECHODIR} "===> ${DIRPRFX}$${entry}.${MACHINE_ARCH}"; \ + ${ECHODIR} "===> ${DIRPRFX}$${entry}.${MACHINE_ARCH} (${.TARGET:realinstall=install})"; \ edir=$${entry}.${MACHINE_ARCH}; \ cd ${.CURDIR}/$${edir}; \ else \ - ${ECHODIR} "===> ${DIRPRFX}$$entry"; \ + ${ECHODIR} "===> ${DIRPRFX}$$entry (${.TARGET:realinstall=install})"; \ edir=$${entry}; \ cd ${.CURDIR}/$${edir}; \ fi; \ ----Next_Part(Mon_Sep__6_16:11:43_2004_055)---- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 22:35:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5EF216A4CE for ; Mon, 6 Sep 2004 22:35:22 +0000 (GMT) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6821043D53 for ; Mon, 6 Sep 2004 22:35:22 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.uk.FreeBSD.org (Ugrondar@localhost [127.0.0.1]) i86MZBDq036235; Mon, 6 Sep 2004 23:35:11 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i86MZAW9036234; Mon, 6 Sep 2004 23:35:10 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.uk.FreeBSD.org: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i86MXxen039742; Mon, 6 Sep 2004 23:34:00 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200409062234.i86MXxen039742@grimreaper.grondar.org> To: "M. Warner Losh" In-Reply-To: Your message of "Mon, 06 Sep 2004 16:11:43 MDT." <20040906.161143.77047315.imp@bsdimp.com> Date: Mon, 06 Sep 2004 23:33:59 +0100 From: Mark Murray cc: arch@FreeBSD.ORG Subject: Re: Change to output X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 22:35:23 -0000 "M. Warner Losh" writes: > Consider the following patch. It includes .... : > notice how it explains nicely why it appears that asn1_compile is > built 3 times (it really isn't, but you have to do the obj, depend and > all parts). NICE! > I've been running these patches, or variations on the theme for over > two years now. I'm thinking it would be good to commit to head. I agree. What might this break? Tinderboxes? Do you have a fix for them too? M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 22:45:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8944416A4D5 for ; Mon, 6 Sep 2004 22:45:23 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9847F43D2F for ; Mon, 6 Sep 2004 22:45:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i86MgsOX087617; Mon, 6 Sep 2004 16:42:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 06 Sep 2004 16:43:20 -0600 (MDT) Message-Id: <20040906.164320.16339975.imp@bsdimp.com> To: mark@grondar.org From: "M. Warner Losh" In-Reply-To: <200409062234.i86MXxen039742@grimreaper.grondar.org> References: <20040906.161143.77047315.imp@bsdimp.com> <200409062234.i86MXxen039742@grimreaper.grondar.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG Subject: Re: Change to output X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 22:45:23 -0000 In message: <200409062234.i86MXxen039742@grimreaper.grondar.org> Mark Murray writes: : "M. Warner Losh" writes: : > Consider the following patch. It includes .... : : : > notice how it explains nicely why it appears that asn1_compile is : > built 3 times (it really isn't, but you have to do the obj, depend and : > all parts). : : NICE! : : > I've been running these patches, or variations on the theme for over : > two years now. I'm thinking it would be good to commit to head. : : I agree. What might this break? Tinderboxes? Do you have a fix for them : too? I have no idea what it might break. That's one reason why I posted it. I don't use tinderbox. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Sep 6 23:14:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B774216A4CE for ; Mon, 6 Sep 2004 23:14:25 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E6F943D45 for ; Mon, 6 Sep 2004 23:14:25 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp47.pn.xcllnt.net (dhcp47.pn.xcllnt.net [192.168.4.247]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id i86NEDXr092440; Mon, 6 Sep 2004 16:14:13 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp47.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp47.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i86NEDWk009930; Mon, 6 Sep 2004 16:14:13 -0700 (PDT) (envelope-from marcel@dhcp47.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp47.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i86NEDBA009929; Mon, 6 Sep 2004 16:14:13 -0700 (PDT) (envelope-from marcel) Date: Mon, 6 Sep 2004 16:14:13 -0700 From: Marcel Moolenaar To: "M. Warner Losh" Message-ID: <20040906231413.GA9906@dhcp47.pn.xcllnt.net> References: <20040906.161143.77047315.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040906.161143.77047315.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: Change to output X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 23:14:25 -0000 On Mon, Sep 06, 2004 at 04:11:43PM -0600, M. Warner Losh wrote: > ===> kerberos5/tools (obj,depend,all) > ===> kerberos5/tools/make-print-version (obj) > ===> kerberos5/tools/make-roken (obj) > ===> kerberos5/tools/asn1_compile (obj) > ===> kerberos5/tools/make-print-version (depend) > ===> kerberos5/tools/make-roken (depend) > ===> kerberos5/tools/asn1_compile (depend) > ===> kerberos5/tools/make-print-version (all) > ===> kerberos5/tools/make-roken (all) > ===> kerberos5/tools/asn1_compile (all) > > I've been running these patches, or variations on the theme for over > two years now. I'm thinking it would be good to commit to head. Excellent timing. I've been seeing recursions into sub-directories yesterday that I couldn't explain, but they sure looked redundant to me (multiple installincludes; I see similar redundancies in the doc build). This change definitely helps to analyze problems. I'm game. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 08:11:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19B8416A4CE for ; Tue, 7 Sep 2004 08:11:00 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9750C43D1F for ; Tue, 7 Sep 2004 08:10:59 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 166D89F5; Tue, 7 Sep 2004 10:11:36 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 3BAD8B85E; Tue, 7 Sep 2004 10:10:58 +0200 (CEST) To: Mark Murray References: <200409062234.i86MXxen039742@grimreaper.grondar.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 07 Sep 2004 10:10:58 +0200 In-Reply-To: <200409062234.i86MXxen039742@grimreaper.grondar.org> (Mark Murray's message of "Mon, 06 Sep 2004 23:33:59 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@FreeBSD.ORG Subject: Re: Change to output X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 08:11:00 -0000 Mark Murray writes: > I agree. What might this break? Tinderboxes? Do you have a fix for > them too? The tinderbox won't care one way or another. Its author agrees that Warner's patch seems like a good idea. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 16:47:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31BDC16A4CE for ; Tue, 7 Sep 2004 16:47:47 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE6C743D49 for ; Tue, 7 Sep 2004 16:47:46 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i87GnIRM028968; Tue, 7 Sep 2004 09:49:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i87GnIGg028967; Tue, 7 Sep 2004 09:49:18 -0700 Date: Tue, 7 Sep 2004 09:49:18 -0700 From: Brooks Davis To: "Richmond J. Platz" Message-ID: <20040907164918.GB17387@odin.ac.hmc.edu> References: <4139FD7A.7040501@usadatanet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKoe5XOeduwbEQHU" Content-Disposition: inline In-Reply-To: <4139FD7A.7040501@usadatanet.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-arch@freebsd.org Subject: Re: Free BSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 16:47:47 -0000 --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 04, 2004 at 10:38:02AM -0700, Richmond J. Platz wrote: > Is Thjis available for Win XP Pro? IF so,What is its Size? No. FreeBSD is an operating system and will replace XP. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBPeaNXY6L6fI4GtQRAmumAJ48PCLdWsfiui7TFecFSUPi3YQ7jwCgp2Rk JuW5J0/mQggf4iU6ZjcFjy8= =G9F6 -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 17:17:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E9C616A4CE for ; Tue, 7 Sep 2004 17:17:17 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F1DA43D2F for ; Tue, 7 Sep 2004 17:17:17 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6A85472DD5; Tue, 7 Sep 2004 10:17:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 67FB172DD4; Tue, 7 Sep 2004 10:17:17 -0700 (PDT) Date: Tue, 7 Sep 2004 10:17:17 -0700 (PDT) From: Doug White To: Poul-Henning Kamp In-Reply-To: <47444.1094470317@critter.freebsd.dk> Message-ID: <20040907101447.U67477@carver.gumbysoft.com> References: <47444.1094470317@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: Thoughts about malloc(3) and threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 17:17:17 -0000 On Mon, 6 Sep 2004, Poul-Henning Kamp wrote: > In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= > writes: > >Poul-Henning Kamp writes: > >> So, short version of my position is: > >> [...] > > > >you forgot the most important part: > > > >"no matter how hard you think it will be to write a good paralell > >allocator, it will be harder than you think" > > Shhhh! you shouldn't have told them that yet. *snicker* Sounds like a project for a bored college student looking for a thesis. Do you know of any references to research papers on the topic? Would some of UMA's fundamentals apply? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 17:34:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E9CC16A4CF for ; Tue, 7 Sep 2004 17:34:35 +0000 (GMT) Received: from plouf.absolight.net (plouf.absolight.net [212.43.217.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55F9043D39 for ; Tue, 7 Sep 2004 17:34:35 +0000 (GMT) (envelope-from mat@FreeBSD.org) X-Original-To: freebsd-arch@freebsd.org Received: from [192.168.1.51] (l15v-8-120.d2.club-internet.fr [62.34.135.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by plouf.absolight.net (Postfix) with ESMTP id 819E73FB8 for ; Tue, 7 Sep 2004 19:34:30 +0200 (CEST) Date: Tue, 07 Sep 2004 19:34:23 +0200 From: Mathieu Arnold To: freebsd-arch@freebsd.org Message-ID: <2B3B72296D192E4E1D43D19C@[192.168.1.51]> In-Reply-To: <20040907164918.GB17387@odin.ac.hmc.edu> References: <4139FD7A.7040501@usadatanet.com> <20040907164918.GB17387@odin.ac.hmc.edu> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========81FA9682AA794791DA83==========" X-Spam-Checker-Version: SpamAssassin 2.64-abso_2004012301 (2004-01-11) on plouf.absolight.net by root@absolight.fr X-Virus-Scanned: by amavisd-new at plouf.absolight.net X-Spam-Status: No, hits=-1.934 tagged_above=-10 required=5 tests=AWL, BAYES_00, J_CHICKENPOX_24, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS, RCVD_IN_SORBS_DUL X-Spam-Level: Subject: Re: Free BSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 17:34:35 -0000 --==========81FA9682AA794791DA83========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline +-Le 07/09/2004 09:49 -0700, Brooks Davis a dit : | On Sat, Sep 04, 2004 at 10:38:02AM -0700, Richmond J. Platz wrote: |> Is Thjis available for Win XP Pro? IF so,What is its Size? | | No. FreeBSD is an operating system and will replace XP. Should I call Microsoft and tell them ? :-) -- Mathieu Arnold --==========81FA9682AA794791DA83========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQT3xIlvROjYJ63c1AQLfxQf9H+BVajcfKlrMB9hjtiTXQEl7lLCCIGRw Oi/AOxnsaQ2HrObrhXpattNgn5Ga4351Dp8bTp1Sa8/WY//a+5ZUv9xUMzKMeoXE l/3JZ+C8ukbPnToyX8JJ0dZ1SuvOcSjxPbkGH6fufcNhBMa+B/oTY2FN/HzQQ0mQ KIdOwj/J0tKmT+s5u6AAElEwQLBurIA/4BHD3ZMLOlxygGTBK63Y0KV/o3V//lKz 8AGUCSOXeP4Wu72Y41938rQxpik9vD5a7C/w5Emymuj2b+e7OZxoPxHkAtsLT3hA mY+2QjG/l4M09d+x8gOoBsY2x9GxN71pIrUmPxn+i1tbU8Qeky6v3A== =Nr8O -----END PGP SIGNATURE----- --==========81FA9682AA794791DA83==========-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 17:42:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A965816A4CE for ; Tue, 7 Sep 2004 17:42:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A5843D41 for ; Tue, 7 Sep 2004 17:42:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i87Hgd4a021976; Tue, 7 Sep 2004 19:42:40 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug White From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 07 Sep 2004 10:17:17 PDT." <20040907101447.U67477@carver.gumbysoft.com> Date: Tue, 07 Sep 2004 19:42:39 +0200 Message-ID: <21975.1094578959@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: Thoughts about malloc(3) and threading. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 17:42:43 -0000 In message <20040907101447.U67477@carver.gumbysoft.com>, Doug White writes: >On Mon, 6 Sep 2004, Poul-Henning Kamp wrote: > >> In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= >> writes: >> >Poul-Henning Kamp writes: >> >> So, short version of my position is: >> >> [...] >> > >> >you forgot the most important part: >> > >> >"no matter how hard you think it will be to write a good paralell >> >allocator, it will be harder than you think" >> >> Shhhh! you shouldn't have told them that yet. > >*snicker* > >Sounds like a project for a bored college student looking for a thesis. >Do you know of any references to research papers on the topic? Would some >of UMA's fundamentals apply? Sun has done some work and I belive it is basically a userland version of UMA. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 08:30:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 511AD16A4CE for ; Wed, 8 Sep 2004 08:30:49 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C6943D1D for ; Wed, 8 Sep 2004 08:30:48 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i888UkGN036514 for ; Wed, 8 Sep 2004 10:30:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Wed, 08 Sep 2004 10:30:46 +0200 Message-ID: <36513.1094632246@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [BIKESHED] Giving abort(2) a reason X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 08:30:49 -0000 A brief talk about malloc's 'A' option on that channel raised again the idea that we should have a variant of abort(2) which takes a reason which will be logged in the syslog buffers so people can see what is wrong rather than just get a core dump. Given that we are usually pretty stumped when we get to call abort(2) it needs to work without malloc or anything like it and varargs into the kernel is not at all in my future. My proposal therefore is a system call something like: abort2(const char *why, int nargs, void **args); this would terminate the process like abort(2) and in addition produce a message in the syslog buffer along these lines: Aborted $procname pid $pid uid $uid gid $gid. Aborted $procname pid $pid $why $arg1 $arg2... A typical usage would be: if (speed > mach1) { void *msg[2]; msg[0] = speed; msg[1] = mach1; abort2("Supersonic speed not supported", 2, msg); } and the output in syslog would be: Aborted sophwith pid 23 uid 100 gid 100. Aborted sophwith pid 23 Supersonic speed not supported 0x4dd 0x3aa Is this workable ? Anyone want to try their hands at an implementation ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 13:05:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2CA416A4CE for ; Wed, 8 Sep 2004 13:05:16 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 334A743D2D for ; Wed, 8 Sep 2004 13:05:13 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i88D2FUl040455 for arch@freebsd.org.checked; (8.12.8/vak/2.1) Wed, 8 Sep 2004 17:02:15 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i88D0Yng040391 for ; (8.12.8/vak/2.1) Wed, 8 Sep 2004 17:00:34 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <413F02E5.9050105@cronyx.ru> Date: Wed, 08 Sep 2004 17:02:29 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: tty code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 13:05:16 -0000 Hi, Does tty code mpsafe ready? Last problem I've had with cx(4) in async mode is that I forget to register swi interrupt as MPSAFE. After that I start to observe panic in ttread. Any ideas? PS. I work with code from 13 Aug 2003, since problems with APIC/ACPI. In more recent code I didn't saw changes that could fix this. rik From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 21:10:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50B5F16A4CE; Wed, 8 Sep 2004 21:10:51 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8923043D46; Wed, 8 Sep 2004 21:10:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i88LAig7047832; Wed, 8 Sep 2004 23:10:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2004 14:58:46 MDT." <20040908.145846.71090050.imp@bsdimp.com> Date: Wed, 08 Sep 2004 23:10:44 +0200 Message-ID: <47831.1094677844@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: green@FreeBSD.org cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb ugen.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 21:10:51 -0000 In message <20040908.145846.71090050.imp@bsdimp.com>, "M. Warner Losh" writes: >It turns out that Brian's change typically is the same as the old >code. However, there are a few cases where it isn't: > >(1) Where the application doesn't close the device when it gets an > error. Stupid application, I know, but in this case the device > never detaches. This is one of the things that caused our > appliction to die with the new code, but not the old code. phk's > work with deadfs and dev_t ref counting may help here. The intent is that devfs will act as isolator for drivers which disintegrate, in other words, even if the application does not close and go away, devfs will make it go away from the drivers point of view. The refcounting necessary is not in place currently, I ran into a funky detail and got derailed. Problem is that we can't just declare that destroy_dev() will evict all threads because we do not know what they might be sleeping on/for while they are inside the driver. A two phase scheme is necesary where the driver first blocks future entry, then evicts any threads already in there and then calls destroy_dev(). I've done some work on this based on the phk_tty branch in p4, but it was pretty exploratory. The challenge with ttys is that the struct tty might referenced as controlling tty even after the last close. Once I get this sorted out, I'll aim at getting phk_tty MFP4'ed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 22:00:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF69F16A4CE for ; Wed, 8 Sep 2004 22:00:57 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C9BC43D2F for ; Wed, 8 Sep 2004 22:00:57 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i88M0tTU079460; Wed, 8 Sep 2004 18:00:55 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i88M0spV079459; Wed, 8 Sep 2004 18:00:54 -0400 (EDT) (envelope-from green) Date: Wed, 8 Sep 2004 18:00:54 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040908220054.GH928@green.homeunix.org> References: <20040908.145846.71090050.imp@bsdimp.com> <47831.1094677844@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47831.1094677844@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb ugen.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 22:00:58 -0000 On Wed, Sep 08, 2004 at 11:10:44PM +0200, Poul-Henning Kamp wrote: > In message <20040908.145846.71090050.imp@bsdimp.com>, "M. Warner Losh" writes: > >It turns out that Brian's change typically is the same as the old > >code. However, there are a few cases where it isn't: > > > >(1) Where the application doesn't close the device when it gets an > > error. Stupid application, I know, but in this case the device > > never detaches. This is one of the things that caused our > > appliction to die with the new code, but not the old code. phk's > > work with deadfs and dev_t ref counting may help here. > > The intent is that devfs will act as isolator for drivers which > disintegrate, in other words, even if the application does not close > and go away, devfs will make it go away from the drivers point of > view. The refcounting necessary is not in place currently, I ran > into a funky detail and got derailed. > > Problem is that we can't just declare that destroy_dev() will evict > all threads because we do not know what they might be sleeping > on/for while they are inside the driver. A two phase scheme is > necesary where the driver first blocks future entry, then evicts > any threads already in there and then calls destroy_dev(). > > I've done some work on this based on the phk_tty branch in p4, but > it was pretty exploratory. The challenge with ttys is that the > struct tty might referenced as controlling tty even after the last > close. > > Once I get this sorted out, I'll aim at getting phk_tty MFP4'ed. FWIW, this is also interesting from a network driver standpoint which has little to do with dev. It would be nice to make all ifnets devs.... -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 17:05:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A09816A4CF for ; Thu, 9 Sep 2004 17:05:14 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CC8A43D5A for ; Thu, 9 Sep 2004 17:05:13 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 55382 invoked from network); 9 Sep 2004 17:01:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 17:01:31 -0000 Message-ID: <41408D4C.E33B6F98@freebsd.org> Date: Thu, 09 Sep 2004 19:05:16 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John-Mark Gurney References: <20040906050435.GA72089@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: better MTU support... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 17:05:14 -0000 John-Mark Gurney wrote: > > In a recent experiment w/ Jumbo frames, I found out that sending ip > frames completely ignores the MTU set on host routes. This makes it > difficult (or next to impossible) to support a network that has both > regular and jumbo frames on it as you can't restrict some hosts to the > smaller frames. What you should do instead is to set the MTU on the interface to 9018 or so and then have a default route with MTU 1500 for everything else. Now you can specify larger MTUs for hosts that support it. Otherwise you are opening a can of worms... > I now have a patch to ip_output that makes it obay the MTU set on the > route instead of that of the interface. Your patch corrects a problem in ip_output where a smaller MTU on an rtentry was ignored but that is only for the non-TCP cases. When you open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). If not it would be a bug. Could you try your large MTU setup again using the procedure I desribed above? That should solve your immediate problem. For the general 'bug' in ip_output that it doesn't honour a smaller MTU on a route I'd like to do a more throughout fix. Routes should be created with MTU 0 if the MTU is not different from the if_mtu. Only in those cases where you want to have a lower MTU you set it. For cloned routes the MTU would be cloned from the parent. This range of changes is more intrusive. On top of that comes the new ARP code which will have a MTU field as well. This one is supposed to store different MTUs for mixed MTU L2 networks. How to transport the MTU information is a separate discussion. If the fix above works for you I'd like to do the real fix later (< end of year) and not change the current behaviour in ip_output at the moment. -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 17:15:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95A5716A4CE for ; Thu, 9 Sep 2004 17:15:17 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37B4243D4C for ; Thu, 9 Sep 2004 17:15:17 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 29553 invoked from network); 9 Sep 2004 17:15:16 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 17:15:16 -0000 Received: from hydrogen.funkthat.com (uxoxqv@localhost.funkthat.com [127.0.0.1])i89HFGuU073713; Thu, 9 Sep 2004 10:15:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i89HFFCG073712; Thu, 9 Sep 2004 10:15:15 -0700 (PDT) Date: Thu, 9 Sep 2004 10:15:15 -0700 From: John-Mark Gurney To: Andre Oppermann Message-ID: <20040909171515.GL72089@funkthat.com> Mail-Followup-To: Andre Oppermann , freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20040906050435.GA72089@funkthat.com> <41408D4C.E33B6F98@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41408D4C.E33B6F98@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: better MTU support... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 17:15:17 -0000 Andre Oppermann wrote this message on Thu, Sep 09, 2004 at 19:05 +0200: > John-Mark Gurney wrote: > > > > In a recent experiment w/ Jumbo frames, I found out that sending ip > > frames completely ignores the MTU set on host routes. This makes it > > difficult (or next to impossible) to support a network that has both > > regular and jumbo frames on it as you can't restrict some hosts to the > > smaller frames. > > What you should do instead is to set the MTU on the interface to 9018 > or so and then have a default route with MTU 1500 for everything else. > Now you can specify larger MTUs for hosts that support it. > > Otherwise you are opening a can of worms... Actually, this will still be broken, since host routes on the local segment will be cloned from the link/net route, and ip will still try to use the if mtu... which is set to 9018... TCP works fine, the problem is using UDP in a mixed environment... > > I now have a patch to ip_output that makes it obay the MTU set on the > > route instead of that of the interface. > > Your patch corrects a problem in ip_output where a smaller MTU on an > rtentry was ignored but that is only for the non-TCP cases. When you > open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). > If not it would be a bug. TCP works fine, the problem is with icmp and udp and other types.. duplicating the MTU logic in each would seem excesive... > Could you try your large MTU setup again using the procedure I desribed > above? Turns out that my hub can't do jumbo frames.. so I can't completely test it beyound the simulation of 1000 being the normal MTU, and 1500 being "jumbo"... > That should solve your immediate problem. As I said, I'm pretty sure this would still break other hosts, since the issue I'm talking about doesn't touch the default route... > For the general 'bug' in ip_output that it doesn't honour a smaller MTU > on a route I'd like to do a more throughout fix. Routes should be > created with MTU 0 if the MTU is not different from the if_mtu. Only > in those cases where you want to have a lower MTU you set it. For cloned > routes the MTU would be cloned from the parent. This range of changes is > more intrusive. On top of that comes the new ARP code which will have a > MTU field as well. This one is supposed to store different MTUs for mixed > MTU L2 networks. How to transport the MTU information is a separate > discussion. > > If the fix above works for you I'd like to do the real fix later (< end > of year) and not change the current behaviour in ip_output at the moment. Sorry, I can't test it.. :( I stupidly assumed that all gige equipment supported jumbo frames... it was never a high priority, but as gige stuff is cheap, this is going to become more of an issue, and wanted to preemptively fix it.. Esspecially how cool 5.3-R is from a networking perspective. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."