From owner-freebsd-arch@FreeBSD.ORG Sun Jul 1 23:08:57 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E630416A400 for ; Sun, 1 Jul 2007 23:08:57 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 98EA813C458 for ; Sun, 1 Jul 2007 23:08:57 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l61N8sp0010144 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Jul 2007 19:08:56 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 1 Jul 2007 16:08:35 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: arch@freebsd.org Message-ID: <20070701160540.Y552@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: wakeup_flags patch. 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, 01 Jul 2007 23:08:58 -0000 http://people.freebsd.org/~jeff/wakeupflags.diff It didn't workout very cleanly since the flags have to go through three layers. I could define wakeup and sleepq flags to be the same and skip a bunch of conditionals. However, we'd then have to know which flags were free to use in each case. Are there any further opinions on the style? This patch does not include an implementation for WAKEUP_LOCAL. I'm still working on that in SCHED_SMP. Ironically, it does include an implementation for WAKEUP_TAIL, however, I don't have any users of that. :-) Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 07:42:45 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A15816A41F for ; Mon, 2 Jul 2007 07:42:45 +0000 (UTC) (envelope-from elan619xi@yahoo.com) Received: from web38501.mail.mud.yahoo.com (web38501.mail.mud.yahoo.com [209.191.125.47]) by mx1.freebsd.org (Postfix) with SMTP id AF06D13C4BC for ; Mon, 2 Jul 2007 07:42:44 +0000 (UTC) (envelope-from elan619xi@yahoo.com) Received: (qmail 18299 invoked by uid 60001); 2 Jul 2007 07:16:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=j+XQr0iDx7p65nce96NfFTM0HYp3QN4RuYpTs8NEPZLwT+TDo1Yhs5Uohj8B9lfiOqs7S06rqbnUOKyCaJxf4eEEAcICmbmJPxtAf0hAAZwxYbWbGl5dHlTNMnVn0IVcbzBuB0p2BE1xIFuzyUr2rfXRWrWJ5BitkXH7Mc/JUoQ=; X-YMail-OSG: gkSaXuUVM1mjJ6XkBfJcovdeeYmshkspoonTPdxTBTVemjoEFiR0qSOYXGzoScrHk9bXYlrqqfeYYr9DhlajUK9JWq9.KhA0kG.zY9wTYAt1gEkdA_tsdBCoDXdX7Q-- Received: from [209.191.106.127] by web38501.mail.mud.yahoo.com via HTTP; Mon, 02 Jul 2007 00:16:03 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Mon, 2 Jul 2007 00:16:03 -0700 (PDT) From: Elan Marikit To: freebsd-arch@freebsd.org MIME-Version: 1.0 Message-ID: <651163.18171.qm@web38501.mail.mud.yahoo.com> X-Mailman-Approved-At: Mon, 02 Jul 2007 11:34:47 +0000 Content-Type: text/plain; charset=ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [TEST/REVIEW] CPU accounting patches 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, 02 Jul 2007 07:42:45 -0000 Greetz list, Do we have already a patch for 6.2. Thanks, ELan ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 16:35:39 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A35816A469 for ; Mon, 2 Jul 2007 16:35:39 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (redqueen.elvandar.org [217.148.169.55]) by mx1.freebsd.org (Postfix) with ESMTP id 9357C13C4C1 for ; Mon, 2 Jul 2007 16:35:38 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from evilcoder.xs4all.nl ([195.64.94.120] helo=elvandar.local) by galain.elvandar.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I5OVu-000C2T-Ki; Mon, 02 Jul 2007 18:12:34 +0200 Message-ID: <46892402.5000907@FreeBSD.org> Date: Mon, 02 Jul 2007 18:12:50 +0200 From: Remko Lodder User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Elan Marikit References: <651163.18171.qm@web38501.mail.mud.yahoo.com> In-Reply-To: <651163.18171.qm@web38501.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: [TEST/REVIEW] CPU accounting patches 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, 02 Jul 2007 16:35:39 -0000 Elan Marikit wrote: > Greetz list, > > Do we have already a patch for 6.2. > > Thanks, > ELan > > > Hello, We have loads of patches for 6.2, but perhaps you can be a bit more specific for people just tuning in and didn't follow the previous part? (At least I just tuned in and I totally do not understand what this is about :)). Cheers, remko -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 18:56:22 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCAB016A481; Mon, 2 Jul 2007 18:56:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7004F13C457; Mon, 2 Jul 2007 18:56:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l62ItX4N097083; Mon, 2 Jul 2007 14:55:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 2 Jul 2007 14:54:39 -0400 User-Agent: KMail/1.9.6 References: <20070701160540.Y552@10.0.0.1> In-Reply-To: <20070701160540.Y552@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707021454.39923.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Jul 2007 14:55:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3574/Mon Jul 2 04:07:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: wakeup_flags patch. 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, 02 Jul 2007 18:56:22 -0000 On Sunday 01 July 2007 07:08:35 pm Jeff Roberson wrote: > http://people.freebsd.org/~jeff/wakeupflags.diff > > It didn't workout very cleanly since the flags have to go through three > layers. I could define wakeup and sleepq flags to be the same and skip a > bunch of conditionals. However, we'd then have to know which flags were > free to use in each case. Are there any further opinions on the style? > > This patch does not include an implementation for WAKEUP_LOCAL. I'm still > working on that in SCHED_SMP. Ironically, it does include an > implementation for WAKEUP_TAIL, however, I don't have any users of that. > :-) You can find the pre-threadlock patch for 7.x of what Y! uses for accept() at www.freebsd.org/~jhb/patches/justone.patch It has two features your WAKEUP_TAIL doesn't have (one of which I mentioned earlier): 1) it doesn't wakeup threads from swapped out processes (you aren't getting a thread that is "hot" in the cache if you have to go page it back in from disk), and 2) it returns a success/fail to the caller so that it can fallback to its traditional behavior if we couldn't find a "hot" thread to resume. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 18:56:22 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCAB016A481; Mon, 2 Jul 2007 18:56:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7004F13C457; Mon, 2 Jul 2007 18:56:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l62ItX4N097083; Mon, 2 Jul 2007 14:55:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 2 Jul 2007 14:54:39 -0400 User-Agent: KMail/1.9.6 References: <20070701160540.Y552@10.0.0.1> In-Reply-To: <20070701160540.Y552@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707021454.39923.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Jul 2007 14:55:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3574/Mon Jul 2 04:07:06 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: wakeup_flags patch. 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, 02 Jul 2007 18:56:22 -0000 On Sunday 01 July 2007 07:08:35 pm Jeff Roberson wrote: > http://people.freebsd.org/~jeff/wakeupflags.diff > > It didn't workout very cleanly since the flags have to go through three > layers. I could define wakeup and sleepq flags to be the same and skip a > bunch of conditionals. However, we'd then have to know which flags were > free to use in each case. Are there any further opinions on the style? > > This patch does not include an implementation for WAKEUP_LOCAL. I'm still > working on that in SCHED_SMP. Ironically, it does include an > implementation for WAKEUP_TAIL, however, I don't have any users of that. > :-) You can find the pre-threadlock patch for 7.x of what Y! uses for accept() at www.freebsd.org/~jhb/patches/justone.patch It has two features your WAKEUP_TAIL doesn't have (one of which I mentioned earlier): 1) it doesn't wakeup threads from swapped out processes (you aren't getting a thread that is "hot" in the cache if you have to go page it back in from disk), and 2) it returns a success/fail to the caller so that it can fallback to its traditional behavior if we couldn't find a "hot" thread to resume. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 19:06:26 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BE8016A421; Mon, 2 Jul 2007 19:06:26 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3249113C46E; Mon, 2 Jul 2007 19:06:26 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l62J6OEP029068 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:06:25 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 2 Jul 2007 12:06:03 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: John Baldwin In-Reply-To: <200707021454.39923.jhb@freebsd.org> Message-ID: <20070702120445.X552@10.0.0.1> References: <20070701160540.Y552@10.0.0.1> <200707021454.39923.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: wakeup_flags patch. 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, 02 Jul 2007 19:06:26 -0000 On Mon, 2 Jul 2007, John Baldwin wrote: > On Sunday 01 July 2007 07:08:35 pm Jeff Roberson wrote: >> http://people.freebsd.org/~jeff/wakeupflags.diff >> >> It didn't workout very cleanly since the flags have to go through three >> layers. I could define wakeup and sleepq flags to be the same and skip a >> bunch of conditionals. However, we'd then have to know which flags were >> free to use in each case. Are there any further opinions on the style? >> >> This patch does not include an implementation for WAKEUP_LOCAL. I'm still >> working on that in SCHED_SMP. Ironically, it does include an >> implementation for WAKEUP_TAIL, however, I don't have any users of that. >> :-) > > You can find the pre-threadlock patch for 7.x of what Y! uses for accept() at > www.freebsd.org/~jhb/patches/justone.patch > > It has two features your WAKEUP_TAIL doesn't have (one of which I mentioned > earlier): 1) it doesn't wakeup threads from swapped out processes (you aren't > getting a thread that is "hot" in the cache if you have to go page it back in > from disk), and 2) it returns a success/fail to the caller so that it can > fallback to its traditional behavior if we couldn't find a "hot" thread to > resume. Shouldn't we simply choose a non-hot thread in this case? In your environment is it common to have a lot of swapped out proceses? It would be expensive to lock and unlock each thread to check if it's swapped. Perhaps we can simply do it in a racey way. Jeff > > -- > John Baldwin > From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 19:06:26 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BE8016A421; Mon, 2 Jul 2007 19:06:26 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3249113C46E; Mon, 2 Jul 2007 19:06:26 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l62J6OEP029068 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 15:06:25 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 2 Jul 2007 12:06:03 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: John Baldwin In-Reply-To: <200707021454.39923.jhb@freebsd.org> Message-ID: <20070702120445.X552@10.0.0.1> References: <20070701160540.Y552@10.0.0.1> <200707021454.39923.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: wakeup_flags patch. 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, 02 Jul 2007 19:06:26 -0000 On Mon, 2 Jul 2007, John Baldwin wrote: > On Sunday 01 July 2007 07:08:35 pm Jeff Roberson wrote: >> http://people.freebsd.org/~jeff/wakeupflags.diff >> >> It didn't workout very cleanly since the flags have to go through three >> layers. I could define wakeup and sleepq flags to be the same and skip a >> bunch of conditionals. However, we'd then have to know which flags were >> free to use in each case. Are there any further opinions on the style? >> >> This patch does not include an implementation for WAKEUP_LOCAL. I'm still >> working on that in SCHED_SMP. Ironically, it does include an >> implementation for WAKEUP_TAIL, however, I don't have any users of that. >> :-) > > You can find the pre-threadlock patch for 7.x of what Y! uses for accept() at > www.freebsd.org/~jhb/patches/justone.patch > > It has two features your WAKEUP_TAIL doesn't have (one of which I mentioned > earlier): 1) it doesn't wakeup threads from swapped out processes (you aren't > getting a thread that is "hot" in the cache if you have to go page it back in > from disk), and 2) it returns a success/fail to the caller so that it can > fallback to its traditional behavior if we couldn't find a "hot" thread to > resume. Shouldn't we simply choose a non-hot thread in this case? In your environment is it common to have a lot of swapped out proceses? It would be expensive to lock and unlock each thread to check if it's swapped. Perhaps we can simply do it in a racey way. Jeff > > -- > John Baldwin > From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 20:02:34 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E309216A421 for ; Mon, 2 Jul 2007 20:02:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6293A13C455 for ; Mon, 2 Jul 2007 20:02:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l62K2NHO097542; Mon, 2 Jul 2007 16:02:23 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Jeff Roberson Date: Mon, 2 Jul 2007 15:54:29 -0400 User-Agent: KMail/1.9.6 References: <20070701160540.Y552@10.0.0.1> <200707021454.39923.jhb@freebsd.org> <20070702120445.X552@10.0.0.1> In-Reply-To: <20070702120445.X552@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707021554.29687.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Jul 2007 16:02:23 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3575/Mon Jul 2 15:19:14 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: wakeup_flags patch. 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, 02 Jul 2007 20:02:35 -0000 On Monday 02 July 2007 03:06:03 pm Jeff Roberson wrote: > On Mon, 2 Jul 2007, John Baldwin wrote: > > > On Sunday 01 July 2007 07:08:35 pm Jeff Roberson wrote: > >> http://people.freebsd.org/~jeff/wakeupflags.diff > >> > >> It didn't workout very cleanly since the flags have to go through three > >> layers. I could define wakeup and sleepq flags to be the same and skip a > >> bunch of conditionals. However, we'd then have to know which flags were > >> free to use in each case. Are there any further opinions on the style? > >> > >> This patch does not include an implementation for WAKEUP_LOCAL. I'm still > >> working on that in SCHED_SMP. Ironically, it does include an > >> implementation for WAKEUP_TAIL, however, I don't have any users of that. > >> :-) > > > > You can find the pre-threadlock patch for 7.x of what Y! uses for accept() at > > www.freebsd.org/~jhb/patches/justone.patch > > > > It has two features your WAKEUP_TAIL doesn't have (one of which I mentioned > > earlier): 1) it doesn't wakeup threads from swapped out processes (you aren't > > getting a thread that is "hot" in the cache if you have to go page it back in > > from disk), and 2) it returns a success/fail to the caller so that it can > > fallback to its traditional behavior if we couldn't find a "hot" thread to > > resume. > > Shouldn't we simply choose a non-hot thread in this case? In your > environment is it common to have a lot of swapped out proceses? It would > be expensive to lock and unlock each thread to check if it's swapped. > Perhaps we can simply do it in a racey way. accept() does a wakeup() actually IIRC. We do have boxes with lots of swapped out processes (though often that can be a sign of an overloaded box). I was mostly submitting this as a known-working patch that has been used under real-world load in at least 4.x through 6.x so that it can be drawn from. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 23:25:18 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EAD016A41F for ; Mon, 2 Jul 2007 23:25:18 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 18E2013C44B for ; Mon, 2 Jul 2007 23:25:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1010901uge for ; Mon, 02 Jul 2007 16:25:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=adkLGzqBdbi4iwKcgVLbrXMvQW1hRn8cnZB+5o14GidoAq+TOe7ks+mRx1PGbtWinL6r0wSaoMa97KvCraRYJtKIq32aq5lOxzKzC5WNEXAwE7K4tkbzNpk3OFuTXIT6vAxiX56zKJ9pJu05oXgXsl/M5wU8Lg7qZSYVBiTRSN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Qg4j+kDFEurW9+824PKNHqsZynXYG8tlOE77DY3bHiYka6UpA0L67/+VhYzpdXbpCoKK2gQoj793BRlqpXufE4IVC8PCdxCWlqKOJE4LmOI1rdUtFIkhTzTk4c5A05HwiALBH3WDFQloS0Apv1AktyXpyxpzC5wTN6OglzkOHa4= Received: by 10.78.147.6 with SMTP id u6mr3215887hud.1183417088012; Mon, 02 Jul 2007 15:58:08 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Mon, 2 Jul 2007 15:58:07 -0700 (PDT) Message-ID: <3bbf2fe10707021558i413eed3cv5c5f38a820e9d249@mail.gmail.com> Date: Tue, 3 Jul 2007 00:58:07 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Jeff Roberson" In-Reply-To: <20070701160540.Y552@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070701160540.Y552@10.0.0.1> X-Google-Sender-Auth: 549b63d37d858390 Cc: arch@freebsd.org Subject: Re: wakeup_flags patch. 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, 02 Jul 2007 23:25:18 -0000 2007/7/2, Jeff Roberson : > http://people.freebsd.org/~jeff/wakeupflags.diff > > It didn't workout very cleanly since the flags have to go through three > layers. I could define wakeup and sleepq flags to be the same and skip a > bunch of conditionals. However, we'd then have to know which flags were > free to use in each case. Are there any further opinions on the style? Honestly, IMHO we should not depend by precise values of flags passed between layers. Your code is clean enough to not require those magics too. Specific to the patch: > +void > +wakeup_flags(void *ident, int flags) > +{ > + int sqflag; > + > + sqflag = SLEEPQ_SLEEP; > + if (flags & WAKEUP_LOCAL) > + sqflag |= SLEEPQ_LOCAL; > + if (flags & WAKEUP_TAIL) > + sqflag |= SLEEPQ_TAIL; > + sleepq_lock(ident); > + if (flags & WAKEUP_ONE) { > + sleepq_signal(ident, sqflag, -1, 0); > + sleepq_release(ident); > + } else if (flags & WAKEUP_ALL) > + sleepq_broadcast(ident, sqflag, -1, 0); > + else > + panic("wakeup_flags: Bad flags %d\n", flags); > +} > + I would arrange this a little bit differently in order to make it homogeneous with other locking primitives: void wakeup_flags(void *ident, int flags) { int sqflag; MPASS(flags & (WAKEUP_ONE | WAKEUP_ALL)); ... if (flags & WAKEUP_ONE) { sleepq_signal(ident, sqflag, -1, 0); sleepq_release(ident); } else sleepq_broadcast(ident, sqflag, -1, 0); } > @@ -943,7 +943,7 @@ > resetpriority(td); > } > td->td_slptime = 0; > - sched_add(td, SRQ_BORING); > + sched_add(td, SRQ_BORING|flags); > } This doesn't imply a style violation? (There are several of this). It should be: sched_add(td, SRQ_BORING | flags); > @@ -716,13 +718,17 @@ > * the tail of sleep queues. > */ > besttd = NULL; > - TAILQ_FOREACH(td, &sq->sq_blocked[queue], td_slpq) { > - if (besttd == NULL || td->td_priority < besttd->td_priority) > - besttd = td; > - } > + if ((flags & SLEEPQ_TAIL) == 0) { > + TAILQ_FOREACH(td, &sq->sq_blocked[queue], td_slpq) { > + if (besttd == NULL || > + td->td_priority < besttd->td_priority) > + besttd = td; > + } > + } else All those brackets here are not really necessary, IMHO. > -void setrunnable(struct thread *); > +void setrunnable(struct thread *, int); Wouldn't be better to have style(9) matching prototypes (with named arguments)? > @@ -88,6 +88,8 @@ > #define SLEEPQ_PAUSE 0x02 /* Used by pause. */ > #define SLEEPQ_SX 0x03 /* Used by an sx lock. */ > #define SLEEPQ_INTERRUPTIBLE 0x100 /* Sleep is interruptible. */ > +#define SLEEPQ_LOCAL 0x200 /* Wake-up on the local cpu. */ > +#define SLEEPQ_TAIL 0x400 /* Wake-up from the tail. */ This is not related to your patch, but this let me think that we should have an effective mask of 0xFF for filtering between consumers and flags (in particular when consumers are checked). However, actually sleepqueues consumers identifier isn't basically used. However, I'd like to see this ported for condvar since I strongly hope one day msleep/wakeup will be deprecated in favor of condvar. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 01:33:54 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20E4616A46B for ; Tue, 3 Jul 2007 01:33:54 +0000 (UTC) (envelope-from elan619xi@yahoo.com) Received: from web38513.mail.mud.yahoo.com (web38513.mail.mud.yahoo.com [209.191.125.59]) by mx1.freebsd.org (Postfix) with SMTP id DF06313C448 for ; Tue, 3 Jul 2007 01:33:53 +0000 (UTC) (envelope-from elan619xi@yahoo.com) Received: (qmail 80921 invoked by uid 60001); 3 Jul 2007 01:33:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Fw3EZb/BTGk1twpJbH4uiZpN1LM2T8YEMEqj1gx1awxuUlnr8rZ+lD7Z/KWpLfLuTs74xMFONqG2uchNk+UTiX9+edzPiyRy18PoVqOfiYbfDynz8Yw7HKFd1kW4NDwHuQTl6Jm1QN6zIVoKHyiGu0ZnoZbP5kbI+K9xJU54u28=; X-YMail-OSG: 010tW4MVM1m2A_KPqfNlDDBdYZY7Fl2nT6d4.hZfhLQ8V8HYEjmUjj2i236GH7eKA0LTVG_Hw1swFFafPCUrUnHl52mYGggc5mY.EcT5_xRJicl0e_QEsvxNYom1_g-- Received: from [68.142.201.144] by web38513.mail.mud.yahoo.com via HTTP; Mon, 02 Jul 2007 18:33:53 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Mon, 2 Jul 2007 18:33:53 -0700 (PDT) From: Elan Marikit To: Remko Lodder MIME-Version: 1.0 Message-ID: <337625.80892.qm@web38513.mail.mud.yahoo.com> Content-Type: text/plain; charset=ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: [TEST/REVIEW] CPU accounting patches 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: Tue, 03 Jul 2007 01:33:54 -0000 Hello, I mean the per-CPU accounting patch. What I want to do is to monitor the load of my machine per CPU. Thanks, ELan ----- Original Message ---- From: Remko Lodder To: Elan Marikit Cc: freebsd-arch@freebsd.org Sent: Tuesday, July 3, 2007 12:12:50 AM Subject: Re: [TEST/REVIEW] CPU accounting patches Elan Marikit wrote: > Greetz list, > > Do we have already a patch for 6.2. > > Thanks, > ELan > > > Hello, We have loads of patches for 6.2, but perhaps you can be a bit more specific for people just tuning in and didn't follow the previous part? (At least I just tuned in and I totally do not understand what this is about :)). Cheers, remko -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 06:21:13 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4805D16A400 for ; Tue, 3 Jul 2007 06:21:13 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 12A3713C45A for ; Tue, 3 Jul 2007 06:21:12 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l636LAAN055926 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Jul 2007 02:21:11 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 2 Jul 2007 23:20:48 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: arch@freebsd.org Message-ID: <20070702230728.E552@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Fine grain select locking. 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: Tue, 03 Jul 2007 06:21:13 -0000 I have a diff which makes the following improvements to select: 1) Per-thread wait channel rather than global select wait channel. 2) Per-thread select lock. 3) Rescan after sleep scans only descriptors which have come active. 4) No exposed select internals. 5) selwakeuppri() works again. 6) No thread_lock()ing in select, no TDF_SELECT required. 7) No more collisions. This is based on an approach from Alfred with some locking and rescan improvements by me. It only required changing select users in cases where they assumed only one thread could select at a time. The unfortunate cost of this patch is that a descriptor per select fd must be allocated to track individual threads. This is what allows us to know which descriptor has fired an event and allows us to use per-thread locking etc. The one thing I haven't fixed is netsmb and netncp which both have some wonky select implementation that could be replaced with kern_select(). That could be done seperately from this patch but is required for this to go in. http://people.freebsd.org/~jeff/select.diff Comments and suggestions welcome. Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 07:14:11 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9654B16A421 for ; Tue, 3 Jul 2007 07:14:11 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8812B13C4BB for ; Tue, 3 Jul 2007 07:14:11 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 68B151A4D82; Tue, 3 Jul 2007 00:14:11 -0700 (PDT) Date: Tue, 3 Jul 2007 00:14:11 -0700 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20070703071411.GK45894@elvis.mu.org> References: <20070702230728.E552@10.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070702230728.E552@10.0.0.1> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Fine grain select locking. 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: Tue, 03 Jul 2007 07:14:11 -0000 * Jeff Roberson [070702 23:21] wrote: > I have a diff which makes the following improvements to select: > > 1) Per-thread wait channel rather than global select wait channel. > 2) Per-thread select lock. > 3) Rescan after sleep scans only descriptors which have come active. > 4) No exposed select internals. > 5) selwakeuppri() works again. > 6) No thread_lock()ing in select, no TDF_SELECT required. > 7) No more collisions. > > This is based on an approach from Alfred with some locking and rescan > improvements by me. It only required changing select users in cases where > they assumed only one thread could select at a time. > > The unfortunate cost of this patch is that a descriptor per select fd must > be allocated to track individual threads. This is what allows us to know > which descriptor has fired an event and allows us to use per-thread > locking etc. > > The one thing I haven't fixed is netsmb and netncp which both have some > wonky select implementation that could be replaced with kern_select(). > That could be done seperately from this patch but is required for this to > go in. > > http://people.freebsd.org/~jeff/select.diff > > Comments and suggestions welcome. Sounds cool. I really wish that the rescan wouldn't be needed. I think in practice select or poll returning more than 1-4 descriptors ready doesn't happen so it's not that big of a deal, but still. :) Also, have you thought of a cache per-thread for the selfd? There's actually two places for this cache -it's hard to see if you're already doing this but- one is a cache for the bits copied in for select/poll, the other is a cache for the selfds, so that a process selecting on the same fds does not need to allocate/free N "selfd"s per iteration of select. Also, while doing this work, I found that using slightly more descriptive names for the components helps to keep things more readable. Instead of "selfd" -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 07:39:49 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 031D116A468 for ; Tue, 3 Jul 2007 07:39:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E7D3513C487 for ; Tue, 3 Jul 2007 07:39:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CA5BD1A4D80; Tue, 3 Jul 2007 00:39:48 -0700 (PDT) Date: Tue, 3 Jul 2007 00:39:48 -0700 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20070703073948.GN45894@elvis.mu.org> References: <20070702230728.E552@10.0.0.1> <20070703071411.GK45894@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070703071411.GK45894@elvis.mu.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Fine grain select locking. 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: Tue, 03 Jul 2007 07:39:49 -0000 * Alfred Perlstein [070703 00:14] wrote: > > Also, while doing this work, I found that using slightly more > descriptive names for the components helps to keep things more > readable. Instead of "selfd" *oops* Instead of "selfd" i used "selnote" (like a knote). Note the near collision with "selfd/seltd". -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 01:16:08 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D845816A400 for ; Wed, 4 Jul 2007 01:16:08 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id A28CD13C484 for ; Wed, 4 Jul 2007 01:16:08 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l641G6Or092417 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Jul 2007 21:16:07 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 3 Jul 2007 18:15:41 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: arch@freebsd.org In-Reply-To: <20070702230728.E552@10.0.0.1> Message-ID: <20070703181242.T552@10.0.0.1> References: <20070702230728.E552@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Fine grain select locking. 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, 04 Jul 2007 01:16:08 -0000 Here is an update that avoids the malloc per fd when there are no collisions. This unfortunately adds 64bytes to every socket in the system. This is less than 10% of the size of the socket. Vnodes only allocate their selinfo structures on demand so this does not cause a per-file overhead. This was suggested by Peter. This patch also uses a vm zone for the selfd structures. I can shrink them slightly by using a SLIST in one case vs TAILQ as well. http://people.freebsd.org/~jeff/select2.diff Thanks, Jeff On Mon, 2 Jul 2007, Jeff Roberson wrote: > I have a diff which makes the following improvements to select: > > 1) Per-thread wait channel rather than global select wait channel. > 2) Per-thread select lock. > 3) Rescan after sleep scans only descriptors which have come active. > 4) No exposed select internals. > 5) selwakeuppri() works again. > 6) No thread_lock()ing in select, no TDF_SELECT required. > 7) No more collisions. > > This is based on an approach from Alfred with some locking and rescan > improvements by me. It only required changing select users in cases where > they assumed only one thread could select at a time. > > The unfortunate cost of this patch is that a descriptor per select fd must be > allocated to track individual threads. This is what allows us to know which > descriptor has fired an event and allows us to use per-thread locking etc. > > The one thing I haven't fixed is netsmb and netncp which both have some wonky > select implementation that could be replaced with kern_select(). That could > be done seperately from this patch but is required for this to go in. > > http://people.freebsd.org/~jeff/select.diff > > Comments and suggestions welcome. > > Thanks, > Jeff > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 01:40:48 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C58916A400 for ; Wed, 4 Jul 2007 01:40:48 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id B8B0213C447 for ; Wed, 4 Jul 2007 01:40:47 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so234363uge for ; Tue, 03 Jul 2007 18:40:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=VmzoyIfb5pKpndjdHJIDprRfUayoIadntLiJuT6soYIcBp/qK9uQBAm1FsUfbpiPNWURPihmInEvluAY5MtFnfJMvSIFFilGZnYr65aLNdEgiP6oWMYXqtNbogl+B926IbDWkB2VwwjpwVi31TIiSf7pbHSH0Big38gagReKEsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=kFpc1MYu1gfINVZk+qHedgUGFFjfF37OoP7H+1DWxYhSx6XcsH0kfeODYH13wjBKbWbdFeM5Ohmcc+AstUsGIv/23th5mhXnkRvnraSNWib0udOWVGjBE8z3GYprNg7O10weBAis2wvTi4SH8bNwO+5YmxEJ5Mn9idG2dMuDePo= Received: by 10.78.201.15 with SMTP id y15mr3877909huf.1183513246449; Tue, 03 Jul 2007 18:40:46 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Tue, 3 Jul 2007 18:40:46 -0700 (PDT) Message-ID: <3bbf2fe10707031840p211bffcci915468975a348ead@mail.gmail.com> Date: Wed, 4 Jul 2007 03:40:46 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: a2c4dcbcdb842f74 Cc: Subject: [PATCH] LDT handling bugfixing 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, 04 Jul 2007 01:40:48 -0000 Hello, Here there is a patch I'd like more people could test out before to commit. This basically addresses 2 problems tegge pointed out to me about actual ia32 LDT handlings affecting i386_ldt_grow and set_user_ldt_rv: - Basically, when an LDT entry is updated in the struct proc_ldt of the specified process, what happens is that old entry is freed before the entries in the gdt and the ldtr are updated. This can have huge consequences in particular on SMP environments. - Currently when ldt changes for a proc running on a particular CPU, other threads sharing the same ldt, running on other CPUs, need to update their entries too. Unfortunalty, current code assumes that thread which can share LDT are all in the same process, which is not entirely correct since it doesn't take in account process creating with rfork() where parent and child shares the same VM. This patch should address these two problems and doing a cleanup switching the usage of refcnt interface to use the old-style refcount which is faster for this case. kib alredy reviewed the patch, and other reviews are not only welcome but encouraged. I'm looking, in particular, for people testing at it, in particular if they can run linuxthreads library: http://users.gufi.org/~rookie/works/patches/smpng07032007.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 10:55:26 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26BC116A46E for ; Wed, 4 Jul 2007 10:55:26 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 18EBE13C447 for ; Wed, 4 Jul 2007 10:55:26 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id F37211A4D80; Wed, 4 Jul 2007 03:55:25 -0700 (PDT) Date: Wed, 4 Jul 2007 03:55:25 -0700 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20070704105525.GU45894@elvis.mu.org> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070703181242.T552@10.0.0.1> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Fine grain select locking. 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, 04 Jul 2007 10:55:26 -0000 * Jeff Roberson [070703 18:16] wrote: > Here is an update that avoids the malloc per fd when there are no > collisions. This unfortunately adds 64bytes to every socket in the > system. This is less than 10% of the size of the socket. Vnodes only > allocate their selinfo structures on demand so this does not cause a > per-file overhead. This was suggested by Peter. This patch also uses a > vm zone for the selfd structures. I can shrink them slightly by using a > SLIST in one case vs TAILQ as well. > > http://people.freebsd.org/~jeff/select2.diff Jeff, I understand you're trying to speed up mysql micro benchmarks, but have you done any benchmarking on large select operations? You seemed very dismissive when I brought up caching of the selfd objects and malloc'd bitmap space per-thread on IRC, so I'd like to know if that was based on anything. What are the numbers before and after for selecting on 1000 or maybe 10000 descriptors before and after your patch? This is especially important if you'd like it in the door for 7.0, right? -Alfred > > Thanks, > Jeff > > On Mon, 2 Jul 2007, Jeff Roberson wrote: > > >I have a diff which makes the following improvements to select: > > > >1) Per-thread wait channel rather than global select wait channel. > >2) Per-thread select lock. > >3) Rescan after sleep scans only descriptors which have come active. > >4) No exposed select internals. > >5) selwakeuppri() works again. > >6) No thread_lock()ing in select, no TDF_SELECT required. > >7) No more collisions. > > > >This is based on an approach from Alfred with some locking and rescan > >improvements by me. It only required changing select users in cases where > >they assumed only one thread could select at a time. > > > >The unfortunate cost of this patch is that a descriptor per select fd must > >be allocated to track individual threads. This is what allows us to know > >which descriptor has fired an event and allows us to use per-thread > >locking etc. > > > >The one thing I haven't fixed is netsmb and netncp which both have some > >wonky select implementation that could be replaced with kern_select(). > >That could be done seperately from this patch but is required for this to > >go in. > > > >http://people.freebsd.org/~jeff/select.diff > > > >Comments and suggestions welcome. > > > >Thanks, > >Jeff > >_______________________________________________ > >freebsd-arch@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-arch > >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 11:58:45 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4A1F16A421; Wed, 4 Jul 2007 11:58:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 59F3113C483; Wed, 4 Jul 2007 11:58:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C3B6D48B11; Wed, 4 Jul 2007 07:58:44 -0400 (EDT) Date: Wed, 4 Jul 2007 12:58:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20070704105525.GU45894@elvis.mu.org> Message-ID: <20070704124833.W37059@fledge.watson.org> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Fine grain select locking. 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, 04 Jul 2007 11:58:46 -0000 On Wed, 4 Jul 2007, Alfred Perlstein wrote: > * Jeff Roberson [070703 18:16] wrote: > >> Here is an update that avoids the malloc per fd when there are no >> collisions. This unfortunately adds 64bytes to every socket in the system. >> This is less than 10% of the size of the socket. Vnodes only allocate >> their selinfo structures on demand so this does not cause a per-file >> overhead. This was suggested by Peter. This patch also uses a vm zone for >> the selfd structures. I can shrink them slightly by using a SLIST in one >> case vs TAILQ as well. >> >> http://people.freebsd.org/~jeff/select2.diff > > Jeff, I understand you're trying to speed up mysql micro benchmarks, but > have you done any benchmarking on large select operations? I also worry about the narrowness of the benchmarking we're doing -- however, it's hardly new. We do best at optimizing where we have clearly defined targets and measures of performance. The four-times increase in MySQL select performance is a direct result of Kris taking on scalability measurement and helping developers with optimization ideas try them out, profile them, etc. A point I've made at a number of devsummits and elsewhere is that what we really need now is more people to "take ownership" of the performance of workloads they care about. They don't need to be the people to do the optimizations, but if they could help manage outstanding patchsets, measure the change in performance over time, get involved in profiling, etc, then that will have a big effect on performance for the workload, as has happened with MySQL. Here are some workloads I'd really like to see people take responsibility for: - Flat file Apache performance, perhaps with Apachebench or another HTTP throughput measurement tool. - Dynamic Apache performance, perhaps using some combination of Apache/php/MySQL. - BIND query performance with a few realistic-looking workloads. - PostgreSQL performance along the same lines as current MySQL performance. Kris has waved his hands a bit in this direction already and much of the MySQL measurement work can be reused. - Some sort of compiler/build/etc test -- buildworld of HEAD tends to be highly variable over time as components change, compilers change, etc, but optimizing build performance still has a big benefit for developers. Perhaps how long it takes to do the post-buildtools bit of buildworld for a fixed FreeBSD version. - Network micro-benchmarks, including loopback TCP and UDP, multi-machine TCP and UDP, both single stream and multi-stream. - UI interactivity testing -- how long it takes to go from a simultaned keypress from the keyboard device to an input program running in an xterm and other related latency tests that will be affected by scheduling, IPC, and so on. There seem to be two parts of owning a benchmark: - Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, 6.2, 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version perform for the workload using otherwise identical configuration. - Measurement and feedback -- identifying bottlenecks, working with developers to measure the results of specific optimizations, etc, across the life cycle of the patch. If Kris can motivate such a dramatic improvement in MySQL performance, it seems likely that people doing similar things with other workloads could have similar effects. And, as you say, breadth is really important -- tuning the system for MySQL is very important, but has it generally hurt or helped other workloads? In most cases, I'd expect work to date to have helped, because it involved lowering overhead, etc. However, when we get into schedulers, space/time trade-offs, and so on, then that balance will become harder to strike. Robert N M Watson Computer Laboratory University of Cambridge > > You seemed very dismissive when I brought up caching of the selfd objects > and malloc'd bitmap space per-thread on IRC, so I'd like to know if that was > based on anything. > > What are the numbers before and after for selecting on 1000 or maybe 10000 > descriptors before and after your patch? > > This is especially important if you'd like it in the door for 7.0, right? > > -Alfred > > > >> >> Thanks, >> Jeff >> >> On Mon, 2 Jul 2007, Jeff Roberson wrote: >> >>> I have a diff which makes the following improvements to select: >>> >>> 1) Per-thread wait channel rather than global select wait channel. >>> 2) Per-thread select lock. >>> 3) Rescan after sleep scans only descriptors which have come active. >>> 4) No exposed select internals. >>> 5) selwakeuppri() works again. >>> 6) No thread_lock()ing in select, no TDF_SELECT required. >>> 7) No more collisions. >>> >>> This is based on an approach from Alfred with some locking and rescan >>> improvements by me. It only required changing select users in cases where >>> they assumed only one thread could select at a time. >>> >>> The unfortunate cost of this patch is that a descriptor per select fd must >>> be allocated to track individual threads. This is what allows us to know >>> which descriptor has fired an event and allows us to use per-thread >>> locking etc. >>> >>> The one thing I haven't fixed is netsmb and netncp which both have some >>> wonky select implementation that could be replaced with kern_select(). >>> That could be done seperately from this patch but is required for this to >>> go in. >>> >>> http://people.freebsd.org/~jeff/select.diff >>> >>> Comments and suggestions welcome. >>> >>> Thanks, >>> Jeff >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > -- > - Alfred Perlstein > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 15:00:14 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E091616A4A9 for ; Wed, 4 Jul 2007 15:00:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 7714413C483 for ; Wed, 4 Jul 2007 15:00:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so348553uge for ; Wed, 04 Jul 2007 08:00:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=EpMCA9mecBlPB1ErQgl78JptSOLXztfl3fIiVJypwfRLyK82551SrFCL/Miq+NsBSfZgOdRxDq/bzUzvGVmQQ6wsyNGhOLVLecoXGMA+tRvRE999FXM+79fAd1BfZhLroduSKLS73epOlnDxSE2hpbWapwPba4cFFb0uPxD2Ou4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=EcJ2a4kcFrFNN4o0iK6mbcLBr/qaEHtRYXy+YdpkwkZFxDRmUA3YEy+S3LEDSDUzGhv9XY1J5+CNP7eCkrwVNKK06cDw7HdE5Ct1M1m0xzIsoOmslRgqlYDlioSwcr5+aOivq0kq2Qt+NeXSCj5i8fRDtx1XECs/Qz83mJ+bwgY= Received: by 10.78.159.7 with SMTP id h7mr4185195hue.1183561213063; Wed, 04 Jul 2007 08:00:13 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Wed, 4 Jul 2007 08:00:13 -0700 (PDT) Message-ID: <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> Date: Wed, 4 Jul 2007 17:00:13 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: <20070704124833.W37059@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> X-Google-Sender-Auth: 2faf3a3033cd8ed1 Cc: arch@freebsd.org, Alfred Perlstein Subject: Re: Fine grain select locking. 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, 04 Jul 2007 15:00:15 -0000 2007/7/4, Robert Watson : > There seem to be two parts of owning a benchmark: > > - Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, 6.2, > 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version > perform for the workload using otherwise identical configuration. > > - Measurement and feedback -- identifying bottlenecks, working with developers > to measure the results of specific optimizations, etc, across the life cycle > of the patch. Another problem here would be about the hardware availabilty (obviously I'm speaking about scalability improvements). Until now, tests have been done mainly on amd64 machines provided by Kris and Jeff, IIRC. Having a wider range of targets would help a lot in these cases. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 16:46:36 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C71B16A400; Wed, 4 Jul 2007 16:46:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C13A913C4E7; Wed, 4 Jul 2007 16:46:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id F413949366; Wed, 4 Jul 2007 12:46:34 -0400 (EDT) Date: Wed, 4 Jul 2007 17:46:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> Message-ID: <20070704174511.C67251@fledge.watson.org> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Alfred Perlstein Subject: Re: Fine grain select locking. 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, 04 Jul 2007 16:46:36 -0000 On Wed, 4 Jul 2007, Attilio Rao wrote: > 2007/7/4, Robert Watson : >> There seem to be two parts of owning a benchmark: >> >> - Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, >> 6.2, >> 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version >> perform for the workload using otherwise identical configuration. >> >> - Measurement and feedback -- identifying bottlenecks, working with >> developers >> to measure the results of specific optimizations, etc, across the life >> cycle >> of the patch. > > Another problem here would be about the hardware availabilty (obviously I'm > speaking about scalability improvements). Until now, tests have been done > mainly on amd64 machines provided by Kris and Jeff, IIRC. Having a wider > range of targets would help a lot in these cases. The FreeBSD Foundation is currently working on updating the Netperf test cluster from dual-cpu HTT boxes to 8-core systems, and from 1gbps to 10gbps ethernet. Hopefully this will improve access to larger multicore systems for developers without local hardware. This project has been "in progress" for a while now, but will wrap up soon. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 17:19:10 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C01EB16A400; Wed, 4 Jul 2007 17:19:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD0A13C484; Wed, 4 Jul 2007 17:19:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1I68I6-000Mog-2z; Wed, 04 Jul 2007 13:05:22 -0400 Date: Wed, 4 Jul 2007 13:05:22 -0400 From: Gary Palmer To: Robert Watson Message-ID: <20070704170522.GB53564@in-addr.com> Mail-Followup-To: Robert Watson , Attilio Rao , arch@freebsd.org, Alfred Perlstein References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> <20070704174511.C67251@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070704174511.C67251@fledge.watson.org> Cc: Attilio Rao , arch@freebsd.org, Alfred Perlstein Subject: Re: Fine grain select locking. 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, 04 Jul 2007 17:19:10 -0000 On Wed, Jul 04, 2007 at 05:46:34PM +0100, Robert Watson wrote: > > On Wed, 4 Jul 2007, Attilio Rao wrote: > > >2007/7/4, Robert Watson : > >>There seem to be two parts of owning a benchmark: > >> > >>- Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, > >>6.2, > >> 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version > >> perform for the workload using otherwise identical configuration. > >> > >>- Measurement and feedback -- identifying bottlenecks, working with > >>developers > >> to measure the results of specific optimizations, etc, across the life > >>cycle > >> of the patch. > > > >Another problem here would be about the hardware availabilty (obviously > >I'm speaking about scalability improvements). Until now, tests have been > >done mainly on amd64 machines provided by Kris and Jeff, IIRC. Having a > >wider range of targets would help a lot in these cases. > > The FreeBSD Foundation is currently working on updating the Netperf test > cluster from dual-cpu HTT boxes to 8-core systems, and from 1gbps to 10gbps > ethernet. Hopefully this will improve access to larger multicore systems > for developers without local hardware. This project has been "in progress" > for a while now, but will wrap up soon. Hi Robert, Another way of looking at Attilio's message is that we need to focus on more than one type of platform. In addition to benchmarking any differences between large 8 core Opteron and Xeon systems and the Sun "CoolThreads" platform, we need to maintain scalability on "more affordable" single core hardware as well. An immediate thought is embedded type systems such as the Soekris. While high-end server farms have always been our bread and butter, I think widening our focus might be worthwhile. I might have missed it, but I don't remember results being published to ensure that while SMP systems gain performance that we don't adversely impact UP systems in the process. (My memory is far from perfect, apologies if I'm wrong) Regards, Gary From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 18:48:04 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A8FD16A400; Wed, 4 Jul 2007 18:48:04 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 50B0013C448; Wed, 4 Jul 2007 18:48:04 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l64Im1qx030509 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 14:48:02 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 4 Jul 2007 11:47:35 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Alfred Perlstein In-Reply-To: <20070704105525.GU45894@elvis.mu.org> Message-ID: <20070704114005.X552@10.0.0.1> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Fine grain select locking. 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, 04 Jul 2007 18:48:04 -0000 On Wed, 4 Jul 2007, Alfred Perlstein wrote: > * Jeff Roberson [070703 18:16] wrote: >> Here is an update that avoids the malloc per fd when there are no >> collisions. This unfortunately adds 64bytes to every socket in the >> system. This is less than 10% of the size of the socket. Vnodes only >> allocate their selinfo structures on demand so this does not cause a >> per-file overhead. This was suggested by Peter. This patch also uses a >> vm zone for the selfd structures. I can shrink them slightly by using a >> SLIST in one case vs TAILQ as well. >> >> http://people.freebsd.org/~jeff/select2.diff > > Jeff, I understand you're trying to speed up mysql micro benchmarks, > but have you done any benchmarking on large select operations? I don't know that I'd call mysql a micro-benchmark. This patch also didn't help there as much as I had hoped and I'm still trying to understand why. > > You seemed very dismissive when I brought up caching of the selfd > objects and malloc'd bitmap space per-thread on IRC, so I'd like > to know if that was based on anything. Caching the selfd objects would have a tremendous impact on storage overhead. I'm not sure how valuable caching the bits is. We avoid the malloc using the following stack allocation in most cases: fd_mask s_selbits[howmany(2048, NFDBITS)]; If you're interested in further optimizing that I welcome you to it. My motivation as to address the locking without significantly altering other characteristics. If you wanted to cache the bits you might also be able to cache the selfd registration and do something similar to selrescan(). This would have to be done very carefully to avoid semantic changes. > > What are the numbers before and after for selecting on 1000 > or maybe 10000 descriptors before and after your patch? I agree this needs to be done. Diane Bruce has a patch to improve the instruction cost of scanning the fds as well. She has a test framework for select and has most graciously offered to do these measurements. > > This is especially important if you'd like it in the door > for 7.0, right? I decided I wouldn't even propose that. I think it's premature and needs to be studied more. Thanks, Jeff > > -Alfred > > > >> >> Thanks, >> Jeff >> >> On Mon, 2 Jul 2007, Jeff Roberson wrote: >> >>> I have a diff which makes the following improvements to select: >>> >>> 1) Per-thread wait channel rather than global select wait channel. >>> 2) Per-thread select lock. >>> 3) Rescan after sleep scans only descriptors which have come active. >>> 4) No exposed select internals. >>> 5) selwakeuppri() works again. >>> 6) No thread_lock()ing in select, no TDF_SELECT required. >>> 7) No more collisions. >>> >>> This is based on an approach from Alfred with some locking and rescan >>> improvements by me. It only required changing select users in cases where >>> they assumed only one thread could select at a time. >>> >>> The unfortunate cost of this patch is that a descriptor per select fd must >>> be allocated to track individual threads. This is what allows us to know >>> which descriptor has fired an event and allows us to use per-thread >>> locking etc. >>> >>> The one thing I haven't fixed is netsmb and netncp which both have some >>> wonky select implementation that could be replaced with kern_select(). >>> That could be done seperately from this patch but is required for this to >>> go in. >>> >>> http://people.freebsd.org/~jeff/select.diff >>> >>> Comments and suggestions welcome. >>> >>> Thanks, >>> Jeff >>> _______________________________________________ >>> freebsd-arch@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > -- > - Alfred Perlstein > From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 19:04:04 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60DCE16A400; Wed, 4 Jul 2007 19:04:04 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3524C13C4AD; Wed, 4 Jul 2007 19:04:04 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l64J413h033261 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 15:04:02 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 4 Jul 2007 12:03:34 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Gary Palmer In-Reply-To: <20070704170522.GB53564@in-addr.com> Message-ID: <20070704114914.M552@10.0.0.1> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> <20070704174511.C67251@fledge.watson.org> <20070704170522.GB53564@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , arch@freebsd.org, Alfred Perlstein , Robert Watson Subject: Re: Fine grain select locking. 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, 04 Jul 2007 19:04:04 -0000 On Wed, 4 Jul 2007, Gary Palmer wrote: > On Wed, Jul 04, 2007 at 05:46:34PM +0100, Robert Watson wrote: >> >> On Wed, 4 Jul 2007, Attilio Rao wrote: >> >>> 2007/7/4, Robert Watson : >>>> There seem to be two parts of owning a benchmark: >>>> >>>> - Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, >>>> 6.2, >>>> 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version >>>> perform for the workload using otherwise identical configuration. >>>> >>>> - Measurement and feedback -- identifying bottlenecks, working with >>>> developers >>>> to measure the results of specific optimizations, etc, across the life >>>> cycle >>>> of the patch. >>> >>> Another problem here would be about the hardware availabilty (obviously >>> I'm speaking about scalability improvements). Until now, tests have been >>> done mainly on amd64 machines provided by Kris and Jeff, IIRC. Having a >>> wider range of targets would help a lot in these cases. >> >> The FreeBSD Foundation is currently working on updating the Netperf test >> cluster from dual-cpu HTT boxes to 8-core systems, and from 1gbps to 10gbps >> ethernet. Hopefully this will improve access to larger multicore systems >> for developers without local hardware. This project has been "in progress" >> for a while now, but will wrap up soon. > > Hi Robert, > > Another way of looking at Attilio's message is that we need to focus on > more than one type of platform. In addition to benchmarking any differences > between large 8 core Opteron and Xeon systems and the Sun "CoolThreads" > platform, we need to maintain scalability on "more affordable" single > core hardware as well. An immediate thought is embedded type systems > such as the Soekris. While high-end server farms have always been our > bread and butter, I think widening our focus might be worthwhile. I might > have missed it, but I don't remember results being published to ensure > that while SMP systems gain performance that we don't adversely impact > UP systems in the process. (My memory is far from perfect, apologies if > I'm wrong) While I think it's very worthwhile to pick many different targets, I also think we need some sort of priority. My goal has been to optimize for 4-8 core performance for the 7.0 timeframe. We have generally made a lot of decisions to boost SMP performance at the cost of UP performance and I believe that will continue. The trends in processors are towards very affordable multicore packages and 7.0 will probably not be replaced until after 16core dual socket machines are not uncommon. The embedded space is obviously very important as well. However it's a competing optimization in some cases. Hopefully the developers working on embedded platforms can help us to find good compromises or ways to option out expensive things. Thanks, Jeff > > Regards, > > Gary > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 19:05:49 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA57716A421; Wed, 4 Jul 2007 19:05:49 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id AFE1113C447; Wed, 4 Jul 2007 19:05:49 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l64J5lKA033498 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 15:05:48 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 4 Jul 2007 12:05:21 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Attilio Rao In-Reply-To: <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> Message-ID: <20070704120347.M552@10.0.0.1> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Alfred Perlstein , Robert Watson Subject: Re: Fine grain select locking. 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, 04 Jul 2007 19:05:50 -0000 On Wed, 4 Jul 2007, Attilio Rao wrote: > 2007/7/4, Robert Watson : >> There seem to be two parts of owning a benchmark: >> >> - Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, >> 6.2, >> 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version >> perform for the workload using otherwise identical configuration. >> >> - Measurement and feedback -- identifying bottlenecks, working with >> developers >> to measure the results of specific optimizations, etc, across the life >> cycle >> of the patch. > > Another problem here would be about the hardware availabilty > (obviously I'm speaking about scalability improvements). > Until now, tests have been done mainly on amd64 machines provided by > Kris and Jeff, IIRC. > Having a wider range of targets would help a lot in these cases. Yes, definitely. For the scheduler work I often see certain decisions fair worse on different platforms even running the same workload. It would be valuable to me to have a wider array of hardware as well as benchmarks. The netperf cluster helps, but for general scheduler work I also need to know how it fares on a large variety of platforms. Thanks, Jeff > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 19:14:30 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B65D416A41F; Wed, 4 Jul 2007 19:14:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6359A13C468; Wed, 4 Jul 2007 19:14:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 27C2E480D0; Wed, 4 Jul 2007 15:14:30 -0400 (EDT) Date: Wed, 4 Jul 2007 20:14:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: <20070704114914.M552@10.0.0.1> Message-ID: <20070704201124.Q88371@fledge.watson.org> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> <3bbf2fe10707040800p4e003df0p65e2b802f81ec51e@mail.gmail.com> <20070704174511.C67251@fledge.watson.org> <20070704170522.GB53564@in-addr.com> <20070704114914.M552@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , Alfred Perlstein , arch@freebsd.org Subject: Re: Fine grain select locking. 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, 04 Jul 2007 19:14:30 -0000 On Wed, 4 Jul 2007, Jeff Roberson wrote: >> Another way of looking at Attilio's message is that we need to focus on >> more than one type of platform. In addition to benchmarking any >> differences between large 8 core Opteron and Xeon systems and the Sun >> "CoolThreads" platform, we need to maintain scalability on "more >> affordable" single core hardware as well. An immediate thought is embedded >> type systems such as the Soekris. While high-end server farms have always >> been our bread and butter, I think widening our focus might be worthwhile. >> I might have missed it, but I don't remember results being published to >> ensure that while SMP systems gain performance that we don't adversely >> impact UP systems in the process. (My memory is far from perfect, apologies >> if I'm wrong) > > While I think it's very worthwhile to pick many different targets, I also > think we need some sort of priority. My goal has been to optimize for 4-8 > core performance for the 7.0 timeframe. We have generally made a lot of > decisions to boost SMP performance at the cost of UP performance and I > believe that will continue. The trends in processors are towards very > affordable multicore packages and 7.0 will probably not be replaced until > after 16core dual socket machines are not uncommon. > > The embedded space is obviously very important as well. However it's a > competing optimization in some cases. Hopefully the developers working on > embedded platforms can help us to find good compromises or ways to option > out expensive things. Embedded has also gotten really weird lately :-). Embedded can now mean things like multi-core CPUs. I agree we need to maintain breadth, and there are quite a few people who build embedded products on FreeBSD who are hopefully keeping an eye on the direction and performance. I know Sam has observed in the recent past that we've seen quite a bit of instruction count bloat due to focusing on higher end hardware. On higher end hardware, instructions are relatively cheap compared to cache misses, so instruction count may go up less noticeably, especially if the added instructions reduce the cache miss rate. On lower end hardware, those extra instructions can be more prominent in performance results. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 19:43:00 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BF0116A41F for ; Wed, 4 Jul 2007 19:43:00 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id C10AE13C480 for ; Wed, 4 Jul 2007 19:42:59 +0000 (UTC) (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 2BAC11FF94F for ; Wed, 4 Jul 2007 21:17:53 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 6038F1FFACF; Wed, 4 Jul 2007 21:17:46 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 52236444885 for ; Wed, 4 Jul 2007 19:17:33 +0000 (UTC) Date: Wed, 4 Jul 2007 19:17:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: arch@freebsd.org In-Reply-To: <20070704124833.W37059@fledge.watson.org> Message-ID: <20070704191456.G31116@maildrop.int.zabbadoz.net> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704124833.W37059@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: Subject: Re: Fine grain select locking. 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, 04 Jul 2007 19:43:00 -0000 On Wed, 4 Jul 2007, Robert Watson wrote: > I also worry about the narrowness of the benchmarking we're doing -- however, ... > > A point I've made at a number of devsummits and elsewhere is that what we > really need now is more people to "take ownership" of the performance of > workloads they care about. They don't need to be the people to do the > optimizations, but if they could help manage outstanding patchsets, measure > the change in performance over time, get involved in profiling, etc, then > that will have a big effect on performance for the workload, as has happened > with MySQL. > > Here are some workloads I'd really like to see people take responsibility > for: > ... as a side note. A local German IT mag ran a "contest" last year. There is an english translation at http://firebird.sourceforge.net/connect/ct-dbContest.html One thing mentioned there something Dell put together: http://linux.dell.com/dvdstore which might be an interesting "workload" to test for too. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 6 14:10:48 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17EC716A41F; Fri, 6 Jul 2007 14:10:48 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id C433813C43E; Fri, 6 Jul 2007 14:10:47 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E4C198BF755; Fri, 6 Jul 2007 16:10:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPrWOsoyCcNw; Fri, 6 Jul 2007 16:10:44 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D6B178BCEDC; Fri, 6 Jul 2007 16:10:44 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l66EAiqk056934; Fri, 6 Jul 2007 16:10:44 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 6 Jul 2007 16:10:44 +0200 From: Roman Divacky To: arch@freebsd.org Message-ID: <20070706141044.GA56683@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: final version of the *at patch for review 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, 06 Jul 2007 14:10:48 -0000 hi I present the final version of the *at patch for review. Everything what was missing the last version was added. Every issue pointed out was fixed. As far as I know :) The only problematic part I am aware of is auditing. I just reused auditing from the respective non-at counterparts. The patch can be found at: www.vlakno.cz/~rdivacky/linux_at-070706.patch and applied like "cd /sys && patch -p0 < linux_at-070706.patch" you need to rebuild world and kernel to get this working. I tested this using simple regression test: www.vlakno.cz/~rdivacky/doat.c and www.vlakno.cz/~rdivacky/fd.c (the first is to test syscalls the latter to test libc fdopendir). I tried to stick to the POSIX API as described in the draft. Please review this so it can be committed. thank you Roman Divacky From owner-freebsd-arch@FreeBSD.ORG Fri Jul 6 17:43:52 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 641A816A469; Fri, 6 Jul 2007 17:43:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2F55013C458; Fri, 6 Jul 2007 17:43:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.1/8.13.8) with ESMTP id l66HNZRM053111; Fri, 6 Jul 2007 13:23:35 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id l66HNYSe037055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 13:23:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200707061723.l66HNYSe037055@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Jul 2007 13:22:55 -0400 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ), Takeharu KATO From: Mike Tancsa In-Reply-To: <86tzuxni1b.fsf@dwp.des.no> References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: ichwd for ICH8 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, 06 Jul 2007 17:43:52 -0000 At 03:02 AM 5/1/2007, Dag-Erling Sm=F8rgrav wrote: >Takeharu KATO writes: > > I wrote ICH7 or later support patch for sys/dev/ichwd watch dog driver. > > I tested this patch on ICH8 compliant mother board(GIGA BYTE= GA-965P-DS3). > > > > Please apply the patch. > >I will try to take care of this some time within the next two weeks. >Feel free to contact me off-list if you have any updates. Hi, Any chance to commit this to the tree ?=20 It works really well with a number of newer=20 chipsets out there, that the old ichwd does not work with. The patch applies cleanly to both HEAD and=20 RELENG_6. I have it running for some time on a number of RELENG_6 boxes ---Mike=20 From owner-freebsd-arch@FreeBSD.ORG Sat Jul 7 12:51:42 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68A8216A41F for ; Sat, 7 Jul 2007 12:51:42 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 2137413C43E for ; Sat, 7 Jul 2007 12:51:41 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id B595D8BF7F6 for ; Sat, 7 Jul 2007 14:51:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G485mMPsNd0V for ; Sat, 7 Jul 2007 14:51:39 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5454F8BF6A1 for ; Sat, 7 Jul 2007 14:51:39 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l67CpdwR078773 for arch@freebsd.org; Sat, 7 Jul 2007 14:51:39 +0200 (CEST) (envelope-from rdivacky) Date: Sat, 7 Jul 2007 14:51:39 +0200 From: Roman Divacky To: arch@freebsd.org Message-ID: <20070707125139.GA78759@freebsd.org> References: <20070706141044.GA56683@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070706141044.GA56683@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: final version of the *at patch for review 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, 07 Jul 2007 12:51:42 -0000 On Fri, Jul 06, 2007 at 04:10:44PM +0200, Roman Divacky wrote: > hi > > I present the final version of the *at patch for review. Everything > what was missing the last version was added. Every issue pointed out > was fixed. As far as I know :) > > The only problematic part I am aware of is auditing. I just reused auditing > from the respective non-at counterparts. > > The patch can be found at: www.vlakno.cz/~rdivacky/linux_at-070706.patch redefinition of O_EXEC. new patch at www.vlakno.cz/~rdivacky/linux_at-070707.patch