From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 03:08:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61EC5181; Sun, 28 Oct 2012 03:08:30 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 470578FC08; Sun, 28 Oct 2012 03:08:28 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1670926bkc.13 for ; Sat, 27 Oct 2012 20:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PN6YYrBuXwEz5044mLOLnhRINxQRioHHQxKNTOrIQ4Q=; b=bb/Bxrv2VQAeGoNXd7iMcin4gg3ffcwImk1gYgM6idnViehklNS3Xvn0rOVlSO5cLi cjqWYyT3PDVgfe5V6IOOlw1rH+umafFx71mIxUCE5sd4iA+7AiLkTax+QAOqhaiQ5ZiK qTspgUhVbQv8BJQNxB97SFegCrHxu4QaTr1ukixNl56OcVNp2SVzvR3dTNYPhoY5rPqI u3bZtwEfLtyyPgDEtVaQC7t6QMp+Z59KoaZjcQ9NHiRdCjHIvMU3hkF8jwkZWWuvlJ+9 FJd2ncOLjOvhryMG2w8ANnWo26q4rXjN+DaXZu539KvSAg4yLrerp1otX7DXp0gZVB5s LpDA== MIME-Version: 1.0 Received: by 10.204.131.75 with SMTP id w11mr8448420bks.111.1351393708073; Sat, 27 Oct 2012 20:08:28 -0700 (PDT) Received: by 10.205.83.197 with HTTP; Sat, 27 Oct 2012 20:08:28 -0700 (PDT) In-Reply-To: <508C61C1.8090109@FreeBSD.org> References: <508C61C1.8090109@FreeBSD.org> Date: Sat, 27 Oct 2012 20:08:28 -0700 Message-ID: Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) From: hiren panchasara To: Pedro Giffuni Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 03:08:30 -0000 On Sat, Oct 27, 2012 at 3:35 PM, Pedro Giffuni wrote: > Hello Hiren; > > > > On 10/27/2012 16:48, hiren panchasara wrote: > > + Sean, who has been helping me. > > On Sat, Oct 27, 2012 at 2:31 PM, Chris Rees wrote: > >> On 27 October 2012 22:17, hiren panchasara >> wrote: >> > [removing the CC list] >> > >> > On Wed, Oct 24, 2012 at 3:36 PM, Pedro Giffuni wrote= : >> > >> >> (cc'ing -ports and cutting most of the rest) >> >> >> >> > From: Eitan Adler >> >> .> >> >> >On 24 October 2012 13:24, Fernando Apestegu=C3=ADa wrote: >> >> >> Also related to that, what about writing a section about redports[= 1] >> >> >> in the porter's handbook[2]? >> >> > >> >> >This is a good documentation task... but we need more *coding* tasks >> as >> >> well. >> >> > >> >> >> >> We do need to port and test patch (1) from NetBSD or DragonFly to >> replace >> >> GNU patch, and this shouldn't be difficult. >> >> >> > >> > Hi Pedro / List, >> > >> > I am not part of google summer of code but I've tried to port patch(1) >> from >> > NetBSD into FreeBSD head. I hope that is okay. >> > >> > Patching was trivial and It _seems_ to be working fine. >> > >> > I would appreciate any ideas around how to test the changes and how to >> > proceed further. >> >> Have you a patch :)? You're right, there shouldn't have been many >> changes needed. >> > > Will prepare a patch and post here as soon as I get a chance :-) > > > This is great news Hiren, Thanks! > > > The stress test for this utility is the ports tree but before that we hav= e > to > know what will change. > Thanks Pedro! I will have a lot of questions as I am a newbie here. :-) > > What needs to be done is: > > 1- Compare the options between our old patch and the new BSD patch. > Will do. > 2- Document this in FreeBSD's wiki. > I think this needs to be done when we are done deciding on diffs and how the changes look, right? Also, I do not think I have write access to the wiki. > 3- Prepare a port for testing. > Does this need to be a port? I thought this would live in /src/usr.bin/patch. Also, I believe this will co-exist with current gnu patch(1). Is that a right assumption? Thank you, Hiren > > Unfortunately I will be very busy for more than a month and I can't > help much but I am sure some other committer will love to follow > on this. > > Thanks for taking the initiative, that's what FreeBSD needs! > > Pedro. > > From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 03:46:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14B2C454 for ; Sun, 28 Oct 2012 03:46:30 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm35-vm6.bullet.mail.gq1.yahoo.com (nm35-vm6.bullet.mail.gq1.yahoo.com [98.136.216.189]) by mx1.freebsd.org (Postfix) with ESMTP id BCF3F8FC12 for ; Sun, 28 Oct 2012 03:46:29 +0000 (UTC) Received: from [98.137.12.175] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2012 03:46:23 -0000 Received: from [208.71.42.198] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2012 03:46:23 -0000 Received: from [127.0.0.1] by smtp209.mail.gq1.yahoo.com with NNFMP; 28 Oct 2012 03:46:23 -0000 X-Yahoo-Newman-Id: 166537.9987.bm@smtp209.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pZOXLyAVM1nNcyx.r.jx1zHznBvg33tiuoJRrpOn9o126yJ 7xPGZsav4f3S0at6yIMyLiV_BWmrXqN5KksgaCsSxZdE0eEyJw9jEwf1xKLd Vwmyg9ys6AyWZmsv23PiSUlPUIAmClLZeZv_dyhsLtOyEE_R0hSrD2bqS3cQ 6RhB1lghIbX3ysmDNEBtP3CQBBW7ndUfcqmCb30NDRYDy4VkxzswqlImMyc9 xHj1jw2q5T9AFAQ.0C0UuTLY_aBVF8I_EAmkQe9I81rXko6E66I9Oes_922a nN9BkAdkRFL093yPfAUNz2Bw288HI_xMG5iJpq09JYPXrlDtr29T1ROE2AeG Hh55pyh.v9cqU4B4WebruSJ5FcAnlqwEkI4iCWlOtqvafSMVZO5DudFUHbmQ mufEJr5QNWricHG_1GxVuTASoGrhAg5vgAgHqlPqjGyux07z9YgtyFWymbkD XmeA_50qRFjA4oivZFemAVZLIvB_HnQ-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.103] (pfg@200.118.157.7 with plain) by smtp209.mail.gq1.yahoo.com with SMTP; 27 Oct 2012 20:46:22 -0700 PDT Message-ID: <508CAA8F.2040701@FreeBSD.org> Date: Sat, 27 Oct 2012 22:46:23 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: hiren panchasara Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) References: <508C61C1.8090109@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 03:46:30 -0000 Hi; On 10/27/2012 22:08, hiren panchasara wrote: > > > On Sat, Oct 27, 2012 at 3:35 PM, Pedro Giffuni > wrote: > > Hello Hiren; > > > > On 10/27/2012 16:48, hiren panchasara wrote: > ... > > > This is great news Hiren, Thanks! > > > The stress test for this utility is the ports tree but before that > we have to > know what will change. > > Thanks Pedro! > I will have a lot of questions as I am a newbie here. :-) > > > What needs to be done is: > > 1- Compare the options between our old patch and the new BSD patch. > > Will do. > > 2- Document this in FreeBSD's wiki. > > I think this needs to be done when we are done deciding on diffs and > how the changes look, right? > Also, I do not think I have write access to the wiki. Well, I am hoping that we don't have to do any hacking on patch to be acceptable but having a table like this would be nice: http://wiki.freebsd.org/SOC2010BenFiedler This is mandatory though, just planning ahead. > > 3- Prepare a port for testing. > > Does this need to be a port? I thought this would live in > /src/usr.bin/patch. > Also, I believe this will co-exist with current gnu patch(1). Is that > a right assumption? > We like to be safe and having it in the ports tree makes it easier to test it on all FreeBSD versions and platforms before it finds it's way into the base system. I know this sounds like a long tedious process but we have a reputation to take care of ;). Creating a new port of this is really easy though; you can probably start with the bsd sort port as a template and check porter's handbook if there is any doubt. Let us know if you need to a place to put of the tarball. Pedro. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 05:02:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C60CE9B0; Sun, 28 Oct 2012 05:02:49 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 9C6988FC0A; Sun, 28 Oct 2012 05:02:49 +0000 (UTC) Received: from Xins-MacBook-Pro.local (unknown [IPv6:2001:470:83bf:0:e039:d0a2:15e2:d431]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 05D7B20EAA; Sat, 27 Oct 2012 22:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1351400569; bh=pLqvPgTE2o+ZDpMwBz96CbvzJWM1Mp84StQSAJeCAdg=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=uZ6W0ncHLsMHkIHOrffr/nXoGa9vu28UiPcFm2EsXKj1xqtPhe7BZu+F+IBD/+dUz ajMXx9CPVaHT3jUaopQhjg+xja3eoSEYIdze0ubsfhHzbhkmMtntCzndJy+42vAyGC tKNuoQfVUZ46MRYXqY//4VJQidv4PenzvyTojVs4= Message-ID: <508CBC78.50704@delphij.net> Date: Sat, 27 Oct 2012 22:02:48 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: hiren panchasara Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Pedro Giffuni X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 05:02:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 10/27/12 2:17 PM, hiren panchasara wrote: > [removing the CC list] > > On Wed, Oct 24, 2012 at 3:36 PM, Pedro Giffuni > wrote: > >> (cc'ing -ports and cutting most of the rest) >> >>> From: Eitan Adler >> .> >>> On 24 October 2012 13:24, Fernando Apesteguía wrote: >>>> Also related to that, what about writing a section about >>>> redports[1] in the porter's handbook[2]? >>> >>> This is a good documentation task... but we need more *coding* >>> tasks as >> well. >>> >> >> We do need to port and test patch (1) from NetBSD or DragonFly to >> replace GNU patch, and this shouldn't be difficult. >> > > Hi Pedro / List, > > I am not part of google summer of code but I've tried to port > patch(1) from NetBSD into FreeBSD head. I hope that is okay. > > Patching was trivial and It _seems_ to be working fine. > > I would appreciate any ideas around how to test the changes and how > to proceed further. I've a version of OpenBSD patch(1) at: http://svnweb.freebsd.org/base/user/delphij/patch/ But I don't have much time to work on it lately, so I wouldn't mind if someone more energized to take over the lead :) Note that if this is intended to replace the current FreeBSD half-GNU patch(1), please make sure that the features are all in your version before proceeding. Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQjLx4AAoJEG80Jeu8UPuzfsgIAKRpxxX2+KYHeHNCiFOVOyd4 V39XPaVocxHajjtGagWTZ4VfFWKhWMwz2vl94wjApkBpDGpE6Vt6/17g8xyAZJ4a krNF+TobXR2LFjUffDgKBNwouwqxnaPk1fm3M0+HJJPCc+O79Im5pEZfOf3J1atV k4Z2qliYjphPXUFjq/6+vUWPt2N35OyxQAtDJrRWGD6j8sKE/uzmGF4jIKibY0Sx Z5wx3q06xdXpvHFFqKU7AZvTu0Jz22S2MEMTV+0OJdOAka8BDWsM9UwIlSdD90VT VgWjv3M0+eZLa7vxhXEzEw/uLfeDsBmuT7zq6CUHFRaMvVGLN99yZu97tpwvy6E= =sHUs -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 08:52:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E190FBA9 for ; Sun, 28 Oct 2012 08:52:45 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9DFC38FC12 for ; Sun, 28 Oct 2012 08:52:45 +0000 (UTC) Received: from p5dc3ecfe.dip.t-dialin.net ([93.195.236.254] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TSOEE-00028S-5W; Sun, 28 Oct 2012 09:28:18 +0100 Message-ID: <508CEC9E.9020509@gwdg.de> Date: Sun, 28 Oct 2012 09:28:14 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121012 Thunderbird/16.0.1 MIME-Version: 1.0 To: Yuri Subject: Re: How to boot FreeBSD and linux from FreeBSD MBR? References: <508B6D9D.9050103@rawbw.com> <508BAC7E.5090406@gmail.com> <508C724F.8090203@rawbw.com> In-Reply-To: <508C724F.8090203@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: matt , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 08:52:45 -0000 On 28.10.2012 01:46 (UTC+2), Yuri wrote: > On 10/27/2012 02:42, matt wrote: >> This means you have grub2. It is slow as molasses and has to be the mbr. >> You could chainload freebsd's partition under a separate entry, like >> Windows The partition bootcode for FreeBSD will boot it from there. You >> can also boot loader or kernel directly from grub, your choice. > > So you are saying I can't keep BSD MBR and boot linux from under it when > linux uses grub2? Maybe, that I missed something. But why do you not boot FreeBSD from that grub2, which was installed by Linux? As Matt suggested, there are at least to possible ways of booting FreeBSD from grub. And I can confirm, that they do work. Rainer > Is it still possible to still use lilo? I vaguely remember that it used > to work like this. > > Yuri From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 10:55:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51C48EAA; Sun, 28 Oct 2012 10:55:27 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id EF7C58FC12; Sun, 28 Oct 2012 10:55:26 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 3284F14E6F68; Sun, 28 Oct 2012 11:55:19 +0100 (CET) X-Virus-Scanned: amavisd-new at !change-mydomain-variable!.example.com Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yizdYkaoO5BK; Sun, 28 Oct 2012 11:55:18 +0100 (CET) Received: from [192.168.1.100] (5403A6BE.catv.pool.telekom.hu [84.3.166.190]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 15B0C14E5F21; Sun, 28 Oct 2012 11:55:18 +0100 (CET) Message-ID: <508D0F11.1060203@kovesdan.org> Date: Sun, 28 Oct 2012 11:55:13 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: hiren panchasara Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 28 Oct 2012 11:19:34 +0000 Cc: freebsd-hackers@freebsd.org, Pedro Giffuni X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 10:55:27 -0000 Em 27-10-2012 23:17, hiren panchasara escreveu: > Hi Pedro / List, > > I am not part of google summer of code but I've tried to port patch(1) from > NetBSD into FreeBSD head. I hope that is okay. > > Patching was trivial and It _seems_ to be working fine. > > I would appreciate any ideas around how to test the changes and how to > proceed further. Hi Hiren, good to hear that someone is working on this! However, porting these utilies is much tougher than it apparently seems. There are much more criteria than just it compiles and works. More specifically, you should make sure that: - It is feature-complete and has at least the features that are present in the current patch. - Features are actually compatible and do the same. The same set of command-line options have to produce identical output. - Performance is not behind the current implementation. - It works fine with multi-byte locales. - As mentioned by someone else, it should be available as a port for testers. And once the above points seem to be ok, you should ask the portmgr team to do a package build with it. It may reveal some problems that you couldn't produce earlier. - And as seen in BSD grep, all of this above may not be enough, there may still be some undiscovered bugs. :) So it should co-exist with the current patch for some time, first as a secondary one and then as the default and only then should the current patch be removed. BSD sort has gone through all of this but BSD grep is still not completed. These utilities are apparently simple but because of their importance, they need to be near to flawless so this makes it a good challenge. I hope you will enjoy hacking and hope you can make some progress in this! Gabor From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 14:07:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF7CDE49; Sun, 28 Oct 2012 14:07:13 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 21C578FC16; Sun, 28 Oct 2012 14:07:12 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1733310bkc.13 for ; Sun, 28 Oct 2012 07:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bbeRhWgLI2iXV0kFTnF0t0YIH4FXNaJmGPEFduOCYsE=; b=Q3A5aoxm00okrry9EXK+bzSvI+5gyO8XNIhbvYVCnLV1nCmbrA9vr+DYoSrZxMOtEV yofsL/SQ85CxQaZGzEEToXMrNrn68+LA0w+S8obFctOBoN4C7WdB7uGE3+vxupuSzYuS bYqlLZyFBC08adPHzY5qsrfRGM5MAdlOcX0p/lo2xN9YEDpWX3MR8CUahabI7v+76LAD 8G2u6K4zNZC6pESVCTsbVXElkZ+BSlcuUDG3N+kVi6pnYsoy+IC7V9yKh0nBbxqS5hzF 0jdQNgxwY4g8/TUCL4PNIaEU9vf5XSYMnHObk6t9aKJttN7NNV+Bms/hjWWeZtS1g2hs Om/w== Received: by 10.204.4.200 with SMTP id 8mr8807145bks.81.1351433231667; Sun, 28 Oct 2012 07:07:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.50.197 with HTTP; Sun, 28 Oct 2012 07:06:41 -0700 (PDT) In-Reply-To: <20121027211032.C161058094@chaos.jnpr.net> References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> <20121025211522.GA32636@dragon.NUXI.org> <3F52B7C9-A7B7-4E0E-87D0-1E67FE5D0BA7@xcllnt.net> <20121025221244.GG3808@ithaqua.etoilebsd.net> <20121026181152.GC44331@dragon.NUXI.org> <20121026204910.E1FFA58094@chaos.jnpr.net> <20121026233225.54FB858094@chaos.jnpr.net> <20121027211032.C161058094@chaos.jnpr.net> From: Chris Rees Date: Sun, 28 Oct 2012 14:06:41 +0000 Message-ID: Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 14:07:13 -0000 On 27 October 2012 22:10, Simon J. Gerraty wrote: > > On Sat, 27 Oct 2012 19:53:56 +0100, Chris Rees writes: >>I'm saying that it's unacceptable to expect people to change their >>systems just to make the ports tree work after we have broken it on a >>supposedly supported version. > > But there's no suggestion of that. > The ports tree would take care of itself. > > The comment about fixing makefiles refered to the concern about things > outside of base/ports. >From your comment, I now understand that we aren't having the same conversation :) Please answer me these to check we're on the same page: Are we planning to replace /usr/bin/make with bmake in the near future? If yes, what changes are we going to make to the ports tree to ensure that -CURRENT can still use it? Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 15:39:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 653921C2 for ; Sun, 28 Oct 2012 15:39:46 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by mx1.freebsd.org (Postfix) with ESMTP id BF3148FC08 for ; Sun, 28 Oct 2012 15:39:45 +0000 (UTC) Received: from i606.localnet ([87.114.227.42]) by avasout07 with smtp id Gffd1k0010vXEjb01ffehe; Sun, 28 Oct 2012 15:39:38 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=XOyyuHdE c=1 sm=1 a=D7118sq8BksopLMhW8NoUw==:17 a=tvFjYeeLK-cA:10 a=yRT9YeEI6sEA:10 a=KdljGRtMWWsA:10 a=8nJEP1OIZ-IA:10 a=7vtFykjVAAAA:8 a=jIxkZHDmzRUA:10 a=6I5d2MoRAAAA:8 a=MX4UKU3uv9fDRpXQw0QA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=D7118sq8BksopLMhW8NoUw==:117 From: Frank Mitchell To: freebsd-hackers@freebsd.org Subject: Re: How to boot FreeBSD and linux from FreeBSD MBR? Date: Sun, 28 Oct 2012 15:28:33 +0000 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; ) References: <508B6D9D.9050103@rawbw.com> In-Reply-To: <508B6D9D.9050103@rawbw.com> MIME-Version: 1.0 Message-Id: <201210281528.33449.mitchell@wyatt672earp.force9.co.uk> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 15:39:46 -0000 Hi Yuri, I've been through this too. The short answer is to install LILO everywhere, once for each time you install a version of Linux. I discovered this from System Rescue CD, which is an obvious piece of kit for this situation. Currently I have the FreeBSD Boot Selector in my MBR, installed from PC-BSD. This means I can boot my four Primary Partitions using F1, F2, F3, F4. F1 actually boots my dedicated Data Partition #1, which is formatted Ext2 so other systems can access it. I installed GRUB here when I installed Debian, and it works. Other times, Debian says this is dangerous, but not when first installing. From here, GRUB can boot Linux versions on other partitions. F2 boots PC-BSD as usual, on Primary Partition #2. F3 boots Debian on Primary Partition #3, using LILO, which I installed on Partition #3 with that Debian release. LILO makes Linux start much like BSD. F4 boots another Debian on Logical Partition #6, using LILO installed on Primary Partition #4. This works even though Partition #4 is an Extended DOS Partition acting as a container. I installed LILO on Logical Partition #6 too, because System Rescue CD suggests this. Logical Partition #5 is my Linux Swap. Using F1 I can boot everything from GRUB too, which would have been essential if I'd had alot of Linuxes in my Extended DOS Partition. Debian's GRUB install seems to detect other Linuxes okay, but it doesn't see BSDs. Though GRUB will boot PC-BSD too: In GRUB, press 'c' to get the GRUB Command Line. "ls -lh" gives information on all my Partitions. "chainloader (hd0,msdos2)+1" accesses PC-BSD on Primary Partition #2. "boot" boots my PC-BSD. BUT: I discovered there was a problem when I had two BSD releases in two Primary Partitions. When I wanted the second BSD, GRUB always booted the first one. This looks like a bug in GRUB. Also I'm sure this whole scheme falls apart if you start moving or resizing your partitions. Yours truly: Frank Mitchell On Saturday 27 October 2012 06:14:05 Yuri wrote: > When I installed ubuntu on another partition, it overwrote BSD MBR with > grub one. > Now grub boots ubuntu without even asking what to boot. > When I tried to restore BSD MBR, BSD boots but linux doesn't. This is > because there is no bootable PBR in linux partition. > When I tried to install grub into PBR on its own partition, like someone > online suggested, it refused with the message that this is dangerous, etc. > > So is there a way to boot both linux and BSD from BSD MBR (by pressing > F2 or whatever)? > Are there quick instructions anywhere? > I just don't want grub to take over the boot process. > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 16:07:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C988A9E; Sun, 28 Oct 2012 16:07:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 645078FC0A; Sun, 28 Oct 2012 16:07:25 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so2104692dad.13 for ; Sun, 28 Oct 2012 09:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dp2kNYDl+RQcsbWcl5AMjbdILHS2hiv5iKY6HiKsvDk=; b=F/zDjIxkrp7Ra+Ym8gD3/CZG+KIISCM6OL3T1PLL0OhtuwNUesid9yZEgu/mV/11mA kDTc4DynJObkd8kTqfG8x2HEQyliDKE9Nd8sAz+GEFcaKzJrpZL3FUUHBeO0w1WgEPbO 5u+b/+3YpgupOVAAPZ7JGroYPWnmbDXVw/GHBqg7cjF6rw9/MeGQxMEbe18PLnX/FZ+m znSUPCvovSEXcws8cz2V4aY0BH6P7G8qysbYIC/gYQSJyOPA3dGU+J142tgLxHPnRIFk p/WWQa+0aFzoqwCZufcl/JDYbUXG0E0TUTuxAPxfyxNoqM6jjQayy4vlmugizrdcDRZ8 pxhw== MIME-Version: 1.0 Received: by 10.68.218.226 with SMTP id pj2mr86538087pbc.33.1351440444845; Sun, 28 Oct 2012 09:07:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 28 Oct 2012 09:07:24 -0700 (PDT) In-Reply-To: <508D0F11.1060203@kovesdan.org> References: <508D0F11.1060203@kovesdan.org> Date: Sun, 28 Oct 2012 09:07:24 -0700 X-Google-Sender-Auth: sYs1RHleJuT0B3EbuBXTyc0D6b8 Message-ID: Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) From: Adrian Chadd To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Pedro Giffuni , hiren panchasara X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 16:07:25 -0000 On 28 October 2012 03:55, Gabor Kovesdan wrote: > Hi Hiren, > > good to hear that someone is working on this! However, porting these > utilies is much tougher than it apparently seems. There are much more > criteria than just it compiles and works. More specifically, you should > make sure that: [snip] * It's totally bug compatible for now with gnu patch/diff. * You write a _lot_ of test cases for the test framework, so people can do automated regression testing on both performance and behaviour. It'd be nice to have more regression testing. :-) Adrian From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 18:47:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53E5C9AC; Sun, 28 Oct 2012 18:47:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5808FC08; Sun, 28 Oct 2012 18:47:26 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3048602pad.13 for ; Sun, 28 Oct 2012 11:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Uyu1GfMmsLFdHsUeepQuWFMxIMEaPlhKJe3xCbvoO/0=; b=NeBVJUdrVroRgG8R9oeJCGPPSojOMtVuny/gnU7yf+9gpcbQc8me6BK4kn5hWeU6pH /ipXsyiQwQxEHpPV1cS2pCnm5e690avJNfgPN0PyPol677KDqlIaOnzjXIVu0OpiHzoo 9Vd62e+yjjruIKU4OLO//FPry2CASvj+rbEv4CO5PqLla8ssl6CPNB7Itg82GSMU5Mfg xneFGSZSuknK6EI84Aj2WblaGHIkxTVZkUT9jNQe9YXwf6QXS/cqqOZtsXt9NUTZOten XMoLKd9EDXJyE5OoNN6sz/RNYX9LdDFBQxjZ+l/GF1BukJgTeRcAlHefH5AthQ30liYi i1kg== MIME-Version: 1.0 Received: by 10.66.74.65 with SMTP id r1mr77519338pav.75.1351450040374; Sun, 28 Oct 2012 11:47:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 28 Oct 2012 11:47:20 -0700 (PDT) In-Reply-To: References: <201210222317.00457.zec@fer.hr> <201210230916.11513.zec@fer.hr> Date: Sun, 28 Oct 2012 11:47:20 -0700 X-Google-Sender-Auth: LkNEQCp-lyJMnxLbuq-53mUk1wo Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec , Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 18:47:27 -0000 ping? Marko - would you be willing to add the if_free() vnet context setup into -HEAD? Hans, what do you think about USB device attach? detach will be covered by the above (I hope!) but we still need to do a CURVNET_SET(vnet0); during hotplug attach. Thanks, Adrian On 23 October 2012 10:37, Adrian Chadd wrote: > On 23 October 2012 00:16, Marko Zec wrote: > >> As already mentioned earlier, I don't terribly object if you'd place >> CURVNET_SET(ifp->if_vnet) inside if_free() and a limited number of similar >> functions, but I don't quite believe this is will enough to solve the >> device_detach() issue without having to touch any of the drivers... > > That's why I'm asking for more/better ideas. > > So far my ideas are: > > * for hotplug insert - do the same as what you're doing during the > kldload and boot device enumeration pass - call CURVNET_SET(vnet0) > * for device unload (hotplug or otherwise) - if vnet isn't set, > implicitly set it to vnet0 > * for the net80211 vaps, they get destroyed in a few places (ioctl > path, device detach path, I'm sure I saw one more) so I have to use > CURVNET_SET(ifp->if_vnet) on those. > > Now, that _should_ fix it for ath(4) and net80211, and it should fix > it for all the other non-USB wireless devices out there. > > Now as for USB - Hans, what do you think? Should we do something > similar? How does VIMAGE work right now with USB wireless and USB > ethernet devices? > > Marko - thanks for persisting with this. I'd like to try and make this > work for 10.0. > > > > Adrian From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 19:13:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4209A445; Sun, 28 Oct 2012 19:13:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D20228FC0A; Sun, 28 Oct 2012 19:13:46 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so5182133obb.13 for ; Sun, 28 Oct 2012 12:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ap+O/nlbV3gjVYp2i7oLgjmJAQ7UyBqleBcBeuF99oQ=; b=G3dMw+aPfZqbdfFZW01Xbs5rJW/hsc6lEMdncbES+B/hZJ9F6B6cHBIPZ9mqeGba5h xUxIOhy8u3M/VIFrm7pjc4uiOMoSeEtRMmKOXnGE6Y5OxRLLxCRnym43nEBQFFsErrWr hnHSwoXf4KpefAtdqhHSNIQxepNmj6PzBTAmILZhZ0i2fxQAiWBUaX5ByEaPFt5JD0IU C+D9qd0bP4OnFRIoRtX298c/51k/kAh3U4KMgi7fypytlYo/XQD5eeW9BKA9K8o9GF0e ikCo6w+zPTazTuAIJAmMrQnAJbMPsyjaXvgvzKwfLcBFZN+z7Xdi6lByFN51sUxGI/MF g0FA== MIME-Version: 1.0 Received: by 10.182.131.100 with SMTP id ol4mr23056249obb.38.1351451626233; Sun, 28 Oct 2012 12:13:46 -0700 (PDT) Received: by 10.76.143.33 with HTTP; Sun, 28 Oct 2012 12:13:46 -0700 (PDT) In-Reply-To: References: <508D0F11.1060203@kovesdan.org> Date: Sun, 28 Oct 2012 12:13:46 -0700 Message-ID: Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Gabor Kovesdan , freebsd-hackers@freebsd.org, Pedro Giffuni , hiren panchasara X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 19:13:47 -0000 On Sun, Oct 28, 2012 at 9:07 AM, Adrian Chadd wrote: > On 28 October 2012 03:55, Gabor Kovesdan wrote: > >> Hi Hiren, >> >> good to hear that someone is working on this! However, porting these >> utilies is much tougher than it apparently seems. There are much more >> criteria than just it compiles and works. More specifically, you should >> make sure that: > > [snip] > > * It's totally bug compatible for now with gnu patch/diff. > * You write a _lot_ of test cases for the test framework, so people > can do automated regression testing on both performance and behaviour. > > It'd be nice to have more regression testing. :-) If you're looking for bug compatibility with GNU patch, I would start with the tests produced by upstream [1] as a base for determining how compatible BSD patch really is. Similar steps could and should have been done for BSD grep [2] (unfortunately GNU sort doesn't have any tests, but if we develop the guts (inputs and expected output) of some tests and commit them back to GNU, I'm sure they would appreciate it). Thanks, -Garrett 1. http://git.savannah.gnu.org/cgit/patch.git/tree/tests 2. http://git.savannah.gnu.org/cgit/grep.git/tree/tests From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 20:01:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9F63E39; Sun, 28 Oct 2012 20:01:02 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 142228FC1C; Sun, 28 Oct 2012 20:01:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1779850bkc.13 for ; Sun, 28 Oct 2012 13:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V+pGt6YVdmerQPUdA7zfO3wCdQBie6i31EIidHe0/yI=; b=T6pI3TKTZGZBA+I9NnB86OIIQ65KvVHrG8yvf4PceNBphnMZi05DEe0pMl1/NZeqZH PBfb0uKSXQ+CvJilKHGFXZJ7qYUyLqyEp+0IKsKjp9ajAQ+c/VzFewPD6w0YdrrLPOex i/2zwKovxe8rSp0IZr8nFf9c1mubCWc8ncrurAMTu0buLccOa4ppDtBNBQVG81yyXdBg GBfLzMLD4xvMzYfIlFRgpL43Tj2MOFhQmZtDnBsSB8OZB7PR+sH2DgaWxSZihTHiBotR MEp2uOasYO6JJ6dTQFxyewXjepWuR5W7oRx3pawLAZ5CEACi0AcJjtHDQLrdG/yiPGIR tKcw== Received: by 10.204.128.201 with SMTP id l9mr8512554bks.66.1351454460876; Sun, 28 Oct 2012 13:01:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.50.197 with HTTP; Sun, 28 Oct 2012 13:00:30 -0700 (PDT) In-Reply-To: <20121028191144.C10F058094@chaos.jnpr.net> References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> <20121025211522.GA32636@dragon.NUXI.org> <3F52B7C9-A7B7-4E0E-87D0-1E67FE5D0BA7@xcllnt.net> <20121025221244.GG3808@ithaqua.etoilebsd.net> <20121026181152.GC44331@dragon.NUXI.org> <20121026204910.E1FFA58094@chaos.jnpr.net> <20121026233225.54FB858094@chaos.jnpr.net> <20121028191144.C10F058094@chaos.jnpr.net> From: Chris Rees Date: Sun, 28 Oct 2012 20:00:30 +0000 Message-ID: Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 20:01:03 -0000 On 28 October 2012 19:11, Simon J. Gerraty wrote: > > On Sun, 28 Oct 2012 14:06:41 +0000, Chris Rees writes: >>Are we planning to replace /usr/bin/make with bmake in the near future? > > That was what I heard, but any such move is dependent on dealing with > ports. The ~sjg/ports2bmake.tar.gz on freefall is the plan I came up > with after the above "requirement" was introduced at last BSDCan. > >>If yes, what changes are we going to make to the ports tree to ensure >>that -CURRENT can still use it? > > If you mean -current (aka head); the plan is to convert ports to bmake > syntax wrt to the 2 conflicting modifiers. At my last test there are > just under 300 makefiles in ports that use the old modifiers. > > Now for < head (ie. /usr/bin/make is an old version), the above ports > tree detects that bmake is not being used, and invokes a shell script > (bmake-sh) to do what was asked. > > That script will look for bmake and if necessary build/install it. > To do that, it creates a temp copy of Mk/*.mk converted back to the old > syntax so that the old make can build and install bmake, and then the > old system is on par with -current. > > That's what I meant by "ports will take care of itself". > The main gap btw in the above, is if a user who does not have privs to > install bmake, is the only person trying to do something with ports. > > The above plan needs to be approved by portmgr, and obviouslty a test > run of building all ports is needed (possibly more than one). > > Does that help? Certainly, thank you. I didn't find it clear when inspecting the tarball (obviously I hadn't read the README clearly enough). I'm going to have to echo John's non-obvious comment however, and I think it would be very helpful to have a clear public writeup, perhaps Q&A style to allay any other such fears. Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 21:05:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E4A5CFA; Sun, 28 Oct 2012 21:05:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id D1EB98FC12; Sun, 28 Oct 2012 21:05:42 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 337992001; Sun, 28 Oct 2012 22:00:33 +0100 From: Hans Petter Selasky To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Sun, 28 Oct 2012 22:02:13 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210282202.13679.hselasky@c2i.net> Cc: freebsd-net@freebsd.org, Marko Zec , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 21:05:44 -0000 Hi, I currently have not tested VIMAGE with USB devices. Detach is the final exit for a USB device. There is also shutdown, but softc still is around. --HPS On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote: > ping? > > Marko - would you be willing to add the if_free() vnet context setup into > -HEAD? > > Hans, what do you think about USB device attach? detach will be > covered by the above (I hope!) but we still need to do a > CURVNET_SET(vnet0); during hotplug attach. > > Thanks, > > > Adrian > > On 23 October 2012 10:37, Adrian Chadd wrote: > > On 23 October 2012 00:16, Marko Zec wrote: > >> As already mentioned earlier, I don't terribly object if you'd place > >> CURVNET_SET(ifp->if_vnet) inside if_free() and a limited number of > >> similar functions, but I don't quite believe this is will enough to > >> solve the device_detach() issue without having to touch any of the > >> drivers... > > > > That's why I'm asking for more/better ideas. > > > > So far my ideas are: > > > > * for hotplug insert - do the same as what you're doing during the > > kldload and boot device enumeration pass - call CURVNET_SET(vnet0) > > * for device unload (hotplug or otherwise) - if vnet isn't set, > > implicitly set it to vnet0 > > * for the net80211 vaps, they get destroyed in a few places (ioctl > > path, device detach path, I'm sure I saw one more) so I have to use > > CURVNET_SET(ifp->if_vnet) on those. > > > > Now, that _should_ fix it for ath(4) and net80211, and it should fix > > it for all the other non-USB wireless devices out there. > > > > Now as for USB - Hans, what do you think? Should we do something > > similar? How does VIMAGE work right now with USB wireless and USB > > ethernet devices? > > > > Marko - thanks for persisting with this. I'd like to try and make this > > work for 10.0. > > > > > > > > Adrian From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 23:02:23 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D656FBE for ; Sun, 28 Oct 2012 23:02:23 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id CD2908FC0C for ; Sun, 28 Oct 2012 23:02:22 +0000 (UTC) Received: from [192.168.1.47] (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id 228F03093E39 for ; Sun, 28 Oct 2012 23:02:21 +0000 (UTC) From: Erik Cederstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: opensolaris B_TRUE and B_FALSE Message-Id: <560EA79C-502B-418C-8BF1-A1BC28E05FD1@cederstrand.dk> Date: Mon, 29 Oct 2012 00:02:20 +0100 To: FreeBSD Hackers Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 23:02:23 -0000 Hello, I'm looking at this Clang analyzer report: = http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-24-amd64/report-uH= 6BjZ.html.gz#EndPath Apart from the actual error, which is a apse = positive, it seems like Clang can't find the macro definitions for = B_TRUE and B_FALSE (if it did, hovering over them would show the macro = definition). These are defined in sys/cddl/compat/opensolaris/sys/types.h as an enum = of type boolean_t as long as _KERNEL is not defined. The only definition = for boolean_t I can find is in sys/sys/types.h but it's only defined if = _KERNEL is defined. I'm sure that ZFS wouldn't work if B_TRUE or B_FALSE were undefined, I = just can't figure out where it's happening. I need a hint :-) Thanks, Erik From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 23:25:36 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 652BE275 for ; Sun, 28 Oct 2012 23:25:36 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D082E8FC0A for ; Sun, 28 Oct 2012 23:25:23 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q9SNPG1J093260 for ; Sun, 28 Oct 2012 17:25:22 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q9SNOqL1003825; Sun, 28 Oct 2012 17:24:52 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: opensolaris B_TRUE and B_FALSE From: Ian Lepore To: Erik Cederstrand In-Reply-To: <560EA79C-502B-418C-8BF1-A1BC28E05FD1@cederstrand.dk> References: <560EA79C-502B-418C-8BF1-A1BC28E05FD1@cederstrand.dk> Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Oct 2012 17:24:52 -0600 Message-ID: <1351466692.1123.346.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 23:25:36 -0000 On Mon, 2012-10-29 at 00:02 +0100, Erik Cederstrand wrote: > Hello, > > I'm looking at this Clang analyzer report: http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-24-amd64/report-uH6BjZ.html.gz#EndPath Apart from the actual error, which is a apse positive, it seems like Clang can't find the macro definitions for B_TRUE and B_FALSE (if it did, hovering over them would show the macro definition). > > These are defined in sys/cddl/compat/opensolaris/sys/types.h as an enum of type boolean_t as long as _KERNEL is not defined. The only definition for boolean_t I can find is in sys/sys/types.h but it's only defined if _KERNEL is defined. > > I'm sure that ZFS wouldn't work if B_TRUE or B_FALSE were undefined, I just can't figure out where it's happening. I need a hint :-) > > Thanks, > Erik Look further up in sys/cddl/compat/opensolaris/sys/types.h, they're also defined (as macros rather than enum) in the KERNEL case. They're also defined (as enum) in sys/gnu/fs/xfs/xfs_types.h. (Once again, SlickEdit pays for itself by answering with one right-click a question that would have been a pain to use grep for.) -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 28 19:11:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 442A9387; Sun, 28 Oct 2012 19:11:54 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE948FC0A; Sun, 28 Oct 2012 19:11:52 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUI2DcRV6wkt+HimBJwB4h6ujsU9wHua7@postini.com; Sun, 28 Oct 2012 12:11:53 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 28 Oct 2012 12:11:45 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9SJBjh59089; Sun, 28 Oct 2012 12:11:45 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id C10F058094; Sun, 28 Oct 2012 12:11:44 -0700 (PDT) To: Chris Rees Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program In-Reply-To: References: <201210020750.23358.jhb@freebsd.org> <201210021037.27762.jhb@freebsd.org> <127FA63D-8EEE-4616-AE1E-C39469DDCC6A@xcllnt.net> <20121025211522.GA32636@dragon.NUXI.org> <3F52B7C9-A7B7-4E0E-87D0-1E67FE5D0BA7@xcllnt.net> <20121025221244.GG3808@ithaqua.etoilebsd.net> <20121026181152.GC44331@dragon.NUXI.org> <20121026204910.E1FFA58094@chaos.jnpr.net> <20121026233225.54FB858094@chaos.jnpr.net> <20 Comments: In-reply-to: Chris Rees message dated "Sun, 28 Oct 2012 14:06:41 -0000." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Sun, 28 Oct 2012 12:11:44 -0700 Message-ID: <20121028191144.C10F058094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Sun, 28 Oct 2012 23:54:48 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 19:11:54 -0000 On Sun, 28 Oct 2012 14:06:41 +0000, Chris Rees writes: >Are we planning to replace /usr/bin/make with bmake in the near future? That was what I heard, but any such move is dependent on dealing with ports. The ~sjg/ports2bmake.tar.gz on freefall is the plan I came up with after the above "requirement" was introduced at last BSDCan. >If yes, what changes are we going to make to the ports tree to ensure >that -CURRENT can still use it? If you mean -current (aka head); the plan is to convert ports to bmake syntax wrt to the 2 conflicting modifiers. At my last test there are just under 300 makefiles in ports that use the old modifiers. Now for < head (ie. /usr/bin/make is an old version), the above ports tree detects that bmake is not being used, and invokes a shell script (bmake-sh) to do what was asked. That script will look for bmake and if necessary build/install it. To do that, it creates a temp copy of Mk/*.mk converted back to the old syntax so that the old make can build and install bmake, and then the old system is on par with -current. That's what I meant by "ports will take care of itself". The main gap btw in the above, is if a user who does not have privs to install bmake, is the only person trying to do something with ports. The above plan needs to be approved by portmgr, and obviouslty a test run of building all ports is needed (possibly more than one). Does that help? --sjg From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 04:42:50 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BF0D913 for ; Mon, 29 Oct 2012 04:42:50 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 522508FC16 for ; Mon, 29 Oct 2012 04:42:50 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q9T4gibZ020398 for ; Sun, 28 Oct 2012 21:42:44 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <508E0944.9080903@rawbw.com> Date: Sun, 28 Oct 2012 21:42:44 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121023 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: 'device atapicam' breaks the build Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 04:42:50 -0000 Following atapicam(4), I added 'device atapicam' into sys/amd64/conf/GENERIC. This causes 'make buildkernel' to fail: ld -d -warn-common -r -d -o zlib.ko.debug zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | xargs -J% objcopy % zlib.ko.debug objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error Also loading it manually with 'kldload atapicam' fails: kldload: can't load atapicam: Exec format error with system log having an error: link_elf_obj: symbol ata_controlcmd undefined What is wrong with atapicam? I need atapicam because section 23.3.3 of handbook suggests that it is a prerequisite for being able to use DVD drive from the vbox guests. Yuri 9.1-RC3 From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 04:52:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42271312 for ; Mon, 29 Oct 2012 04:52:40 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id E293E8FC1A for ; Mon, 29 Oct 2012 04:52:39 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.27]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q9T4qUw4026909; Sun, 28 Oct 2012 22:52:32 -0600 Date: Mon, 29 Oct 2012 11:52:30 +0700 From: Erich Dollansky To: Yuri Subject: Re: 'device atapicam' breaks the build Message-ID: <20121029115230.21872b62@X220.ovitrap.com> In-Reply-To: <508E0944.9080903@rawbw.com> References: <508E0944.9080903@rawbw.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 04:52:40 -0000 Hi, On Sun, 28 Oct 2012 21:42:44 -0700 Yuri wrote: > Following atapicam(4), I added 'device atapicam' into > sys/amd64/conf/GENERIC. This causes 'make buildkernel' to fail: > > ld -d -warn-common -r -d -o zlib.ko.debug zlib.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | > xargs -J% objcopy % zlib.ko.debug > objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols > zlib.ko.debug zlib.ko > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error > > Also loading it manually with 'kldload atapicam' fails: > kldload: can't load atapicam: Exec format error > with system log having an error: link_elf_obj: symbol ata_controlcmd > undefined > > What is wrong with atapicam? > > I need atapicam because section 23.3.3 of handbook suggests that it > is a prerequisite for being able to use DVD drive from the vbox > guests. > > Yuri > > 9.1-RC3 > I found this in my kernel configuration. # # 21.06.12 ed: # # atapicam or ATA_CAM can be defined. We have a try first with this one # removed. Switch both if writing to a DVD fails. # # options ATA_CAM # Handle legacy controllers with CAM # options ATA_STATIC_ID # Static device numbering It looks like you have to disable above's options. Erich From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 07:27:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 414F0B3 for ; Mon, 29 Oct 2012 07:27:51 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 23F048FC08 for ; Mon, 29 Oct 2012 07:27:50 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q9T7Rnlg037680; Mon, 29 Oct 2012 00:27:50 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <508E2FF5.1030705@rawbw.com> Date: Mon, 29 Oct 2012 00:27:49 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121023 Thunderbird/16.0.1 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: 'device atapicam' breaks the build References: <508E0944.9080903@rawbw.com> <20121029115230.21872b62@X220.ovitrap.com> In-Reply-To: <20121029115230.21872b62@X220.ovitrap.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 07:27:51 -0000 On 10/28/2012 21:52, Erich Dollansky wrote: > # options ATA_CAM # Handle > legacy controllers with CAM > # options ATA_STATIC_ID # Static device numbering > > It looks like you have to disable above's options. Unfortunately the root disk on this machine is attached to ata3 and isn't visible when 'device ATA_CAM' is commented out. (mountroot> prompt shows up on boot only listing ahci-compatible disks). Does this mean that in order to see such (older) disks I have to have 'device ATA_CAM'? Or there is some workaround? Does it also mean that atapicam won't load in case such older disks are in use? If yes, why there is such dependency? Yuri From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 08:12:10 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F52D16F for ; Mon, 29 Oct 2012 08:12:10 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id BB8B58FC08 for ; Mon, 29 Oct 2012 08:12:09 +0000 (UTC) Received: from [192.168.1.47] (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id 12574307C419; Mon, 29 Oct 2012 08:12:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: opensolaris B_TRUE and B_FALSE From: Erik Cederstrand In-Reply-To: <1351466692.1123.346.camel@revolution.hippie.lan> Date: Mon, 29 Oct 2012 09:12:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <560EA79C-502B-418C-8BF1-A1BC28E05FD1@cederstrand.dk> <1351466692.1123.346.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:12:10 -0000 Hello Ian, Den 29/10/2012 kl. 00.24 skrev Ian Lepore = : > Look further up in sys/cddl/compat/opensolaris/sys/types.h, they're = also > defined (as macros rather than enum) in the KERNEL case. They're also > defined (as enum) in sys/gnu/fs/xfs/xfs_types.h. (Once again, = SlickEdit > pays for itself by answering with one right-click a question that = would > have been a pain to use grep for.) The code in the report is /sbin/zpool, so I assume it's not KERNEL code. = As I wrote in my email, I can see B_TRUE and B_FALSE are defined as = boolean_t in sys/cddl/compat/opensolaris/sys/types.h But I can't see = that boolean_t is defined anywhere in the included headers as long as = KERNEL is not defined. As far as I can see, sys/gnu/fs/xfs/xfs_types.h = isn't referenced directly or indirectly in any of the headers included = in zpool_main.c. Erik= From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 08:26:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A98C0BB5 for ; Mon, 29 Oct 2012 08:26:47 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 719278FC08 for ; Mon, 29 Oct 2012 08:26:47 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q9T8QklH043345; Mon, 29 Oct 2012 01:26:46 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <508E3DC6.8050702@rawbw.com> Date: Mon, 29 Oct 2012 01:26:46 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121023 Thunderbird/16.0.1 MIME-Version: 1.0 To: Yuri Subject: Re: 'device atapicam' breaks the build References: <508E0944.9080903@rawbw.com> <20121029115230.21872b62@X220.ovitrap.com> <508E2FF5.1030705@rawbw.com> In-Reply-To: <508E2FF5.1030705@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 08:26:47 -0000 On 10/29/2012 00:27, Yuri wrote: > Unfortunately the root disk on this machine is attached to ata3 and > isn't visible when 'device ATA_CAM' is commented out. (mountroot> > prompt shows up on boot only listing ahci-compatible disks). Actually BIOS has the option to present SATA as AHCI, so this solves the problem. Yuri From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 10:15:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4637C751; Mon, 29 Oct 2012 10:15:43 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id BAB8E8FC16; Mon, 29 Oct 2012 10:15:42 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012 11:15:35 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Oct 2012 11:15:35 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Oct 2012 11:15:34 +0100 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Mon, 29 Oct 2012 11:15:23 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210291115.23845.zec@fer.hr> X-OriginalArrivalTime: 29 Oct 2012 10:15:34.0961 (UTC) FILETIME=[55AFCA10:01CDB5BE] Cc: freebsd-net@freebsd.org, Hans Petter Selasky , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:15:43 -0000 On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote: > ping? > > Marko - would you be willing to add the if_free() vnet context setup into > -HEAD? Feel free to do it - though I'd suggest to use the CURVNET_SET_QUIET() variant there, to reduce the console spam with VNET_DEBUG. Marko Index: if.c =================================================================== --- if.c (revision 242304) +++ if.c (working copy) @@ -513,7 +513,9 @@ if (!refcount_release(&ifp->if_refcount)) return; + CURVNET_SET_QUIET(ifp->if_vnet); if_free_internal(ifp); + CURVNET_RESTORE(); } /* From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 10:30:16 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E65FE9D for ; Mon, 29 Oct 2012 10:30:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id EA2228FC08 for ; Mon, 29 Oct 2012 10:30:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:dccf:f72:6e32:6adf] (unknown [IPv6:2001:7b8:3a7:0:dccf:f72:6e32:6adf]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 46B2F5C59; Mon, 29 Oct 2012 11:30:14 +0100 (CET) Message-ID: <508E5AB4.7060209@FreeBSD.org> Date: Mon, 29 Oct 2012 11:30:12 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: opensolaris B_TRUE and B_FALSE References: <560EA79C-502B-418C-8BF1-A1BC28E05FD1@cederstrand.dk> <1351466692.1123.346.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:30:16 -0000 On 2012-10-29 09:12, Erik Cederstrand wrote: > Den 29/10/2012 kl. 00.24 skrev Ian Lepore : >> Look further up in sys/cddl/compat/opensolaris/sys/types.h, they're also >> defined (as macros rather than enum) in the KERNEL case. They're also >> defined (as enum) in sys/gnu/fs/xfs/xfs_types.h. (Once again, SlickEdit >> pays for itself by answering with one right-click a question that would >> have been a pain to use grep for.) > > The code in the report is /sbin/zpool, so I assume it's not KERNEL code. As I wrote in my email, I can see B_TRUE and B_FALSE are defined as boolean_t in sys/cddl/compat/opensolaris/sys/types.h But I can't see that boolean_t is defined anywhere in the included headers as long as KERNEL is not defined. In sys/cddl/compat/opensolaris/sys/types.h, there is: typedef enum { B_FALSE, B_TRUE } boolean_t; This line defines the boolean_t type. Maybe the type itself is never used, but only the enum values. Sort of like a an anonymous enum in C++. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 16:57:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A21AEE72; Mon, 29 Oct 2012 16:57:01 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE7B8FC14; Mon, 29 Oct 2012 16:57:00 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so5011235lag.13 for ; Mon, 29 Oct 2012 09:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I6506+vnYFSYAdhqeMC/wSJhEyjilt+0hTZ8gWfNIxA=; b=GNiXxV57HYH7dP1/rHNBjCB4fUe0Xmk8/ONMBOnQVppd8BoJqZeYvYTSAOHOoMXnZh 2Wg0+nYK0jutPwW23BIJk4ZZTxqFr+UttBQKMMssOvByf3+vukwooNUwgPd9RSSejkUa j6b5Pdwae4jr4Ro289R5OEqXFG0zolYkpBOgRSiGYENPCEW1SLL6mVI0eSNFQEap6gf8 Q8g3+/ui5RZWKQNskT/ZNiUEya9EiCJCCNctX+Pcb+4ZzGwfYq/oxTlGdMdSuFlpS0es 9Gfn1oDjpuQ5AKcyPKNIcFtk0UmYKWpLi82jtshBN5NaVWOj2o6uv4VpFLQsHvyksCDR l4Qg== MIME-Version: 1.0 Received: by 10.112.26.67 with SMTP id j3mr12382188lbg.39.1351529819488; Mon, 29 Oct 2012 09:56:59 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Mon, 29 Oct 2012 09:56:59 -0700 (PDT) In-Reply-To: <506C461F.2050008@FreeBSD.org> References: <50587F8D.9060102@FreeBSD.org> <5058C68B.1010508@FreeBSD.org> <50596019.5060708@FreeBSD.org> <505AF836.7050004@FreeBSD.org> <506C461F.2050008@FreeBSD.org> Date: Mon, 29 Oct 2012 16:56:59 +0000 X-Google-Sender-Auth: LkoTfcF2YQDq5-0J9gdwj01UQ9c Message-ID: Subject: Re: ule+smp: small optimization for turnstile priority lending From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers , Jeff Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 16:57:01 -0000 On Wed, Oct 3, 2012 at 3:05 PM, Andriy Gapon wrote: > on 20/09/2012 16:14 Attilio Rao said the following: >> On 9/20/12, Andriy Gapon wrote: > [snip] >>> The patch works well as far as I can tell. Thank you! >>> There is one warning with full witness enables but it appears to be harmless >>> (so >>> far): >> >> Andriy, >> thanks a lot for your testing and reports you made so far. >> Unfortunately I'm going off for 2 weeks now and I won't work on >> FreeBSD for that timeframe. I will get back to those in 2 weeks then. >> If you want to play more with this idea feel free to extend/fix/etc. >> this patch. > > Unfortunately I haven't found time to work on this further, but I have some > additional thoughts. > > First, I think that the witness message was not benign and it actually warns about > the same kind of deadlock that I originally had. > The problem is that sched_lend_prio() is called with target thread's td_lock held, > which is a lock of tdq on the thread's CPU. Then, in your patch, we acquire > current tdq's lock to modify its load. But if two tdq locks are to be held at the > same time, then they must be locked using tdq_lock_pair, so that lock order is > maintained. With the patch no tdq lock order can be maintained (can arbitrary) > and thus it is possible to run into a deadlock. Indeed. I realized this after thinking about this problem while I was on holiday. > > I see two possibilities here, but don't rule out that there can be more. > > 1. Do something like my patch does. That is, manipulate current thread's tdq in > advance before any other thread/tdq locks are acquired (or td_lock is changed to > point to a different lock and current tdq is unlocked). The API can be made more > generic in nature. E.g. it can look like this: > void > sched_thread_block(struct thread *td, int inhibitor) > { > struct tdq *tdq; > > THREAD_LOCK_ASSERT(td, MA_OWNED); > KASSERT(td == curthread, > ("sched_thread_block: only curthread is supported")); > tdq = TDQ_SELF(); > TDQ_LOCK_ASSERT(tdq, MA_OWNED); > MPASS(td->td_lock == TDQ_LOCKPTR(tdq)); > TD_SET_INHIB(td, inhibitor); > tdq_load_rem(tdq, td); > tdq_setlowpri(tdq, td); > } > > > 2. Try to do things from sched_lend_prio based on curthread's state. This, as it > seems, would require completely lock-less manipulations of current tdq. E.g. for > tdq_load we could use atomic operations (it is already accessed locklessly, but > not modified). But for tdq_lowpri a more elaborate trick would be required like > having a separate field for a temporary value. No, this is not going to work because tdq_lowpri and tdq_load are updated and used in the same critical path (and possibly also other tdq* members in tdq_runqueue_add(), for example, but I didn't bother to also check that). Let me think some more about this and get back to you. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 18:20:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F3B830E for ; Mon, 29 Oct 2012 18:20:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD508FC08 for ; Mon, 29 Oct 2012 18:20:12 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so5088503lag.13 for ; Mon, 29 Oct 2012 11:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=WOAGIdhVx6qRQj9ec05XocN7MdAatLFEZzspNE9mrCU=; b=C7XckAxih0ty90hYtzKKfQLPsQpojA9So7I+mSJRDzWujA6gXfRKLTm+Q3L2D25403 y3XKpYfbzHz2KGZmWcvYa7vGGIcZn5NZddt0L1we57peYljl52tzcfGRYJNDsvZtzqGe 55+GBTcuXN7EL63/0Vwax951QzusJAFB3b+K6SaZwaLuXLVcbyjqG0YwHugfFLsV/DM5 HMBwBVEp7MkWeEral54M3WGn9bsevSBnwAePQwQ+6wVeoi9/IOxzlphLUAp0UPmhuQpU p6j7IA1YKHjB5FM1MZZ9ULrjhPHi0PVxtAYnpr1aoxrg8HQKFgeB4poCN7b1owC+QUqx 6LDw== Received: by 10.152.124.83 with SMTP id mg19mr28023437lab.6.1351534811559; Mon, 29 Oct 2012 11:20:11 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id m6sm3439681lbh.10.2012.10.29.11.20.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 11:20:11 -0700 (PDT) Sender: Alexander Motin Message-ID: <508EC8D9.1050505@FreeBSD.org> Date: Mon, 29 Oct 2012 20:20:09 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Yuri Subject: Re: 'device atapicam' breaks the build Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:20:13 -0000 Hi. I haven't used vbox much, but I guess that mentioned handbook section is outdated. You should not need atapicam at all since FreeBSD 9.0. If you still wish to revert to old ATA stack and so atapicam, look at UPDATING record from 20110424. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 18:59:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 191CAFA5; Mon, 29 Oct 2012 18:59:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 26B4B8FC23; Mon, 29 Oct 2012 18:59:43 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so5122249lag.13 for ; Mon, 29 Oct 2012 11:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6HcYac4HUuI2CPoTurkkC0xIY32IeQnbuToj9Dc1v1c=; b=CYxBSS/Iit8xKCmJ1F1dAtGaMVRMGImCy9Iq+XEtTCZqKXlKwwKYz4+sgzw0rO/Phu qy7KrdvUyz5eAkilX7EFL2LO5M1HsfuKkDryII4QdACenb/njdQMRcG+YXMizEF7dRA6 evt9nqtWmGJplRSV0jwFQ/8p+8CZxQahqh/jiL15kyfPkYtv5esIpWGJvLlBhHf0aZEs mAGa6dwN85ac8021m47TkxFOsW3q8bqDyqAa8gU/IPLX6848f7S8dh2bWli4D+wjK3Jz K8MOwBo9ONXga9YTf7A3kGMxAd5uBU49jr0X7CY4lvZicdyqjLNbzVsp63by970Xpb95 WhJg== MIME-Version: 1.0 Received: by 10.112.28.98 with SMTP id a2mr12033173lbh.110.1351537182882; Mon, 29 Oct 2012 11:59:42 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Mon, 29 Oct 2012 11:59:42 -0700 (PDT) In-Reply-To: References: <50587F8D.9060102@FreeBSD.org> <5058C68B.1010508@FreeBSD.org> <50596019.5060708@FreeBSD.org> <505AF836.7050004@FreeBSD.org> <506C461F.2050008@FreeBSD.org> Date: Mon, 29 Oct 2012 18:59:42 +0000 X-Google-Sender-Auth: Fcs2I4-io58oRYaKUeZHxAvf_C0 Message-ID: Subject: Re: ule+smp: small optimization for turnstile priority lending From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers , Jeff Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:59:45 -0000 On Mon, Oct 29, 2012 at 4:56 PM, Attilio Rao wrote: > On Wed, Oct 3, 2012 at 3:05 PM, Andriy Gapon wrote: >> on 20/09/2012 16:14 Attilio Rao said the following: >>> On 9/20/12, Andriy Gapon wrote: >> [snip] >>>> The patch works well as far as I can tell. Thank you! >>>> There is one warning with full witness enables but it appears to be harmless >>>> (so >>>> far): >>> >>> Andriy, >>> thanks a lot for your testing and reports you made so far. >>> Unfortunately I'm going off for 2 weeks now and I won't work on >>> FreeBSD for that timeframe. I will get back to those in 2 weeks then. >>> If you want to play more with this idea feel free to extend/fix/etc. >>> this patch. >> >> Unfortunately I haven't found time to work on this further, but I have some >> additional thoughts. >> >> First, I think that the witness message was not benign and it actually warns about >> the same kind of deadlock that I originally had. >> The problem is that sched_lend_prio() is called with target thread's td_lock held, >> which is a lock of tdq on the thread's CPU. Then, in your patch, we acquire >> current tdq's lock to modify its load. But if two tdq locks are to be held at the >> same time, then they must be locked using tdq_lock_pair, so that lock order is >> maintained. With the patch no tdq lock order can be maintained (can arbitrary) >> and thus it is possible to run into a deadlock. > > Indeed. I realized this after thinking about this problem while I was > on holiday. > >> >> I see two possibilities here, but don't rule out that there can be more. >> >> 1. Do something like my patch does. That is, manipulate current thread's tdq in >> advance before any other thread/tdq locks are acquired (or td_lock is changed to >> point to a different lock and current tdq is unlocked). The API can be made more >> generic in nature. E.g. it can look like this: >> void >> sched_thread_block(struct thread *td, int inhibitor) >> { >> struct tdq *tdq; >> >> THREAD_LOCK_ASSERT(td, MA_OWNED); >> KASSERT(td == curthread, >> ("sched_thread_block: only curthread is supported")); >> tdq = TDQ_SELF(); >> TDQ_LOCK_ASSERT(tdq, MA_OWNED); >> MPASS(td->td_lock == TDQ_LOCKPTR(tdq)); >> TD_SET_INHIB(td, inhibitor); >> tdq_load_rem(tdq, td); >> tdq_setlowpri(tdq, td); >> } >> >> >> 2. Try to do things from sched_lend_prio based on curthread's state. This, as it >> seems, would require completely lock-less manipulations of current tdq. E.g. for >> tdq_load we could use atomic operations (it is already accessed locklessly, but >> not modified). But for tdq_lowpri a more elaborate trick would be required like >> having a separate field for a temporary value. > > No, this is not going to work because tdq_lowpri and tdq_load are > updated and used in the same critical path (and possibly also other > tdq* members in tdq_runqueue_add(), for example, but I didn't bother > to also check that). Ok, so here I wasn't completely right because td_lowpri and tdq_load are not read in the same critical path (cpu_search() and sched_pickcpu() in the self case). However, I was over-estimating a factor in this patch: I don't think we need to fix real tdq_load for self in that case before cpu_search() because self is handled in a very special way, with its own comparison. I then think that a patch local to sched_pickcpu() on the self path should be enough. This brings us to another bigger issue, however. tdq_lowpri handling is not perfect in that patch. Think about the case where the thread to be switched out is, infact, the lowest priority one. In that case, what happens is that what we should do is recalculating tdq_lowpri which is usually a very expensive operation and requires TDQ self locking to be in place to be brought on correctly. At this point, I would suggest to use the new version of avg_ule.patch which doesn't take into account tdq_lowpri. This means the optimization won't work in all the cases but at least it is a good trade-off with a more hacky version. This also let me wonder about the tdq_lowpri check in the self case, in general. Basically it forces sched_pickcpu() to select self if and only if the new thread to schedule has an higher priority than the lowest one on curcpu. Why is that like this? Exactly this check is used to enforce some sort of fairness? It would be good if Jeff spends a word or two on this check specifically. Anyway the patch that implements what suggested, let me know your thinking about it: http://www.freebsd.org/~attilio/avg_ule2.patch Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 19:16:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CA4E9F6; Mon, 29 Oct 2012 19:16:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3A28FC0A; Mon, 29 Oct 2012 19:16:16 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so4240099lbd.13 for ; Mon, 29 Oct 2012 12:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m01FhFJZuiJxFIxBalbUfF/jK4C0goMW1cI9OSHOKa0=; b=Sh53C21c58J3SgN5fW0iFWf4njHXglR2xpcrGXdNEQUqgRzga+XR0QcEm+huUfvrKJ SbrXkuSigY5AB/6esEXPvqdslXeHHTGZtXb4QakaDYYQpwapTAMQx+YbNeAphfg3Fo3X cVhP62PwLlgr0yyHGnhioMJqOD5s9yqAfJlFuSgj5IIuLaJtedeYJ/D02XZ5J9jAD+TV yUX3mjjNsrtLa8JsaQdwJSjmcmafGmBOp/dQWW6/8NciE7kaCzNhUDjTBQAkwTKDPAJX g2e4VJPcODeKsGZEjMveIkd6hYH/zF0NOfSVay6aV70e+sgie8zvdcFW4riEFTuOe+Hr FMjQ== MIME-Version: 1.0 Received: by 10.112.47.129 with SMTP id d1mr12097638lbn.115.1351538175274; Mon, 29 Oct 2012 12:16:15 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.30.37 with HTTP; Mon, 29 Oct 2012 12:16:15 -0700 (PDT) In-Reply-To: References: <50587F8D.9060102@FreeBSD.org> <5058C68B.1010508@FreeBSD.org> <50596019.5060708@FreeBSD.org> <505AF836.7050004@FreeBSD.org> <506C461F.2050008@FreeBSD.org> Date: Mon, 29 Oct 2012 19:16:15 +0000 X-Google-Sender-Auth: Pxz3vGO4SdZIZ16PU5YDUF9LoKw Message-ID: Subject: Re: ule+smp: small optimization for turnstile priority lending From: Attilio Rao To: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers , Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:16:17 -0000 On Mon, Oct 29, 2012 at 6:59 PM, Attilio Rao wrote: [ trimm ] > This also let me wonder about the tdq_lowpri check in the self case, > in general. Basically it forces sched_pickcpu() to select self if and > only if the new thread to schedule has an higher priority than the > lowest one on curcpu. Why is that like this? Exactly this check is > used to enforce some sort of fairness? > It would be good if Jeff spends a word or two on this check specifically. Also, I've read the code of tdq_setlowpri() more closely and I think the name tdq_lowpri is highly misleading, because that seems to me the *highest* priority thread that gets returned. Said that, this means that self will be selected in sched_pickcpu() if and only if the new thread has an higher priority than all the ones on the self runqueue. Isn't all this a bit too extreme? Assuming that one cpu has only a single high-priority thread and others are very loaded it would likely make sense to not keep loading them but switch to the self one, maybe. > Anyway the patch that implements what suggested, let me know your > thinking about it: > http://www.freebsd.org/~attilio/avg_ule2.patch I was thinking that however, maybe we could do the tdq_choose() calculation if self == target, to have a little more chances to get the optimization in place, eventually. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 29 20:25:23 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38BC5F0A; Mon, 29 Oct 2012 20:25:23 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id E79178FC08; Mon, 29 Oct 2012 20:25:22 +0000 (UTC) Received: from [192.168.1.47] (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id AB3423083082; Mon, 29 Oct 2012 20:25:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: opensolaris B_TRUE and B_FALSE From: Erik Cederstrand In-Reply-To: <508E5AB4.7060209@FreeBSD.org> Date: Mon, 29 Oct 2012 21:25:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <197D04E2-E9CD-44A4-B08B-88F7A56E835D@cederstrand.dk> References: <560EA79C-502B-418C-8BF1-A1BC28E05FD1@cederstrand.dk> <1351466692.1123.346.camel@revolution.hippie.lan> <508E5AB4.7060209@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1499) Cc: Ian Lepore , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:25:23 -0000 Den 29/10/2012 kl. 11.30 skrev Dimitry Andric : > On 2012-10-29 09:12, Erik Cederstrand wrote: >>=20 >> The code in the report is /sbin/zpool, so I assume it's not KERNEL = code. As I wrote in my email, I can see B_TRUE and B_FALSE are defined = as boolean_t in sys/cddl/compat/opensolaris/sys/types.h But I can't see = that boolean_t is defined anywhere in the included headers as long as = KERNEL is not defined. >=20 > In sys/cddl/compat/opensolaris/sys/types.h, there is: >=20 > typedef enum { B_FALSE, B_TRUE } boolean_t; >=20 > This line defines the boolean_t type. Maybe the type itself is never > used, but only the enum values. Sort of like a an anonymous enum in = C++. Ok, so I expected B_FALSE to be defined as 0 explicitly somewhere, = completely missing the point of enums. Embarrassing. Thanks for being = easy on me :-) Erik= From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 06:13:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 547D665D; Tue, 30 Oct 2012 06:13:02 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC8F8FC0A; Tue, 30 Oct 2012 06:13:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so2363832bkc.13 for ; Mon, 29 Oct 2012 23:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ITapKbOWJdi7YvVRma6GTxcZ/83XaHjFilA1h5XdSh0=; b=ItX+CRxxhtrw3uqXEm0ezCZvskR4vwHrindvfKr8I76i4AQT3ZlaB5WSazOUpJPUNz /NwoQjgjCUL/jRg/w9oXZHT6T0oz3Q36Jr+Ndvrs9mXLEDdopEWF1L3VUN96N9TjqYO4 CGUwkVAnG54XcC0KeJ/8/gyhMsZIiLq//KVUpGEQCs8XPtSx2W6V6Xq3uvNRZXaAoxb+ QpmkTNhHtRdwDySgXMa+udu7/SKF15OUDJs2m9wF/usVdRArNDiEFa6O/PX9fCWvGG+l USUsJYj7CCkKjUT5FJDOBsZ8ZlEAJF2CQLNTAM8TInRUQ3FctgResxfEuktcxHLLAtou daww== MIME-Version: 1.0 Received: by 10.204.128.138 with SMTP id k10mr10046933bks.27.1351577580387; Mon, 29 Oct 2012 23:13:00 -0700 (PDT) Received: by 10.205.83.197 with HTTP; Mon, 29 Oct 2012 23:13:00 -0700 (PDT) In-Reply-To: References: <508D0F11.1060203@kovesdan.org> Date: Mon, 29 Oct 2012 23:13:00 -0700 Message-ID: Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) From: hiren panchasara To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Gabor Kovesdan , freebsd-hackers@freebsd.org, Adrian Chadd , Pedro Giffuni X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 06:13:02 -0000 Thank you all for the inputs. I understand this is a long grueling process so I will attempt to do things in approximately following order: 1) prepare a new port for bsd patch 2) make sure new bsd patch has all options of existing gnu patch 3) merge outstanding patches: http://svnweb.freebsd.org/base/head/gnu/usr.bin/patch/?view=log 4) bug compatibility 5) performance cheers, Hiren From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 11:15:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E1E750F for ; Tue, 30 Oct 2012 11:15:51 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id B57128FC1A for ; Tue, 30 Oct 2012 11:15:50 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9UBCTWE030366 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Oct 2012 11:12:29 GMT Date: Tue, 30 Oct 2012 11:12:22 +0000 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:15:51 -0000 Hi All, Can anyone think of any quick pointers as to why some code originally written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes up a *lot* more memory when running? The code involved is a sendmail Milter, and a TCP server type program (that runs up a large number of threads [~700] at startup). Both were previously compiled with: -O2 -pthread -lc_r They're now compiled under 9.0-S with just: -O2 -pthread As an example, under 6.4 the size/res for one reported by top is 81Mb/48Mb - and for the other is 44Mb/9Mb [this is after it's been running for weeks]. Under 9.0-stable the initial memory used by the processes just after starting rises to 625Mb/128Mb and 519Mb/65Mb respectively. Is that something I need to worry about? They've not been running longing enough yet to see if anything is 'leaking' (i.e. if size/res continues to go up). Just thought I'd ask if there's a simple/possible explanation for this - and if it's something I need to worry about... Thanks, -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 11:21:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D8CD642 for ; Tue, 30 Oct 2012 11:21:24 +0000 (UTC) (envelope-from prvs=1650b10a0f=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id BE5258FC08 for ; Tue, 30 Oct 2012 11:21:23 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000877178.msg for ; Tue, 30 Oct 2012 11:21:18 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 30 Oct 2012 11:21:18 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1650b10a0f=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Karl Pielorz" , References: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Date: Tue, 30 Oct 2012 11:21:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:21:24 -0000 ----- Original Message ----- From: "Karl Pielorz" To: Sent: Tuesday, October 30, 2012 11:12 AM Subject: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. > > Hi All, > > Can anyone think of any quick pointers as to why some code originally > written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes up > a *lot* more memory when running? > > The code involved is a sendmail Milter, and a TCP server type program (that > runs up a large number of threads [~700] at startup). > > Both were previously compiled with: > > -O2 -pthread -lc_r > > They're now compiled under 9.0-S with just: > > -O2 -pthread > > > As an example, under 6.4 the size/res for one reported by top is 81Mb/48Mb > - and for the other is 44Mb/9Mb [this is after it's been running for weeks]. > > Under 9.0-stable the initial memory used by the processes just after > starting rises to 625Mb/128Mb and 519Mb/65Mb respectively. > > Is that something I need to worry about? > > They've not been running longing enough yet to see if anything is 'leaking' > (i.e. if size/res continues to go up). Just thought I'd ask if there's a > simple/possible explanation for this - and if it's something I need to > worry about... amd64 vs i386? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 11:27:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91632796 for ; Tue, 30 Oct 2012 11:27:37 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 2A67C8FC16 for ; Tue, 30 Oct 2012 11:27:36 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q9UBRSTD000766; Tue, 30 Oct 2012 05:27:29 -0600 Date: Tue, 30 Oct 2012 18:27:27 +0700 From: Erich Dollansky To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121030182727.48f5e649@X220.ovitrap.com> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:27:37 -0000 Hi, On Tue, 30 Oct 2012 11:12:22 +0000 Karl Pielorz wrote: > Can anyone think of any quick pointers as to why some code originally > written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 > takes up a *lot* more memory when running? > is it still the same compiler? > As an example, under 6.4 the size/res for one reported by top is > 81Mb/48Mb > - and for the other is 44Mb/9Mb [this is after it's been running for > weeks]. > I assume that it is a plain FreeBSD program without X. Erich From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 11:28:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB4AE889 for ; Tue, 30 Oct 2012 11:28:59 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFFF8FC0C for ; Tue, 30 Oct 2012 11:28:58 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9UBSuwe031291 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 11:28:57 GMT Date: Tue, 30 Oct 2012 11:28:49 +0000 From: Karl Pielorz To: Steven Hartland , freebsd-hackers@freebsd.org Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:29:00 -0000 --On 30 October 2012 11:21 +0000 Steven Hartland wrote: >> They've not been running longing enough yet to see if anything is >> 'leaking' (i.e. if size/res continues to go up). Just thought I'd ask >> if there's a simple/possible explanation for this - and if it's >> something I need to worry about... > > amd64 vs i386? Nice try :) - But as I said in my original email (he says, checking again - yup it's in there ;) both the 6.4 and 9.0 systems are amd64... I'd expect the memory usage to 'go up' between the versions for the programs, I'm just concerned by the size increase... -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 11:54:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DEE41B8 for ; Tue, 30 Oct 2012 11:54:08 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id 52B5E8FC16 for ; Tue, 30 Oct 2012 11:54:06 +0000 (UTC) Received: from [78.35.146.160] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TTAHq-0002m3-HO; Tue, 30 Oct 2012 12:47:14 +0100 Date: Tue, 30 Oct 2012 13:46:14 +0100 From: Fabian Keil To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121030134614.1a42f0e3@fabiankeil.de> In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/O_=1nr6K8G9W6NyUtrwbJUS"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:54:08 -0000 --Sig_/O_=1nr6K8G9W6NyUtrwbJUS Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Karl Pielorz wrote: > Can anyone think of any quick pointers as to why some code originally=20 > written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes > up a *lot* more memory when running? 6.4 comes with phkmalloc while 9.0 uses jemalloc. Maybe you are allocating memory in a way that is less space-efficiently handled by jemalloc's default configuration. Fabian --Sig_/O_=1nr6K8G9W6NyUtrwbJUS Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCPzBoACgkQBYqIVf93VJ3T/gCfVUdIjii6Xms+s52XRXUg0sYe WOAAoJ+is+vl/Pa+qWorSwSbYY2TYGzi =+oWx -----END PGP SIGNATURE----- --Sig_/O_=1nr6K8G9W6NyUtrwbJUS-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 11:59:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8E632E4 for ; Tue, 30 Oct 2012 11:59:16 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 90FCE8FC12 for ; Tue, 30 Oct 2012 11:59:15 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TTATS-0002Xh-Lg for freebsd-hackers@freebsd.org; Tue, 30 Oct 2012 04:59:14 -0700 Date: Tue, 30 Oct 2012 04:59:14 -0700 (PDT) From: Jakub Lach To: freebsd-hackers@freebsd.org Message-ID: <1351598354663-5756476.post@n5.nabble.com> In-Reply-To: References: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:59:16 -0000 If this is only difference between gcc34 v gcc42 it's quite spectacular... -- View this message in context: http://freebsd.1045724.n5.nabble.com/Threaded-6-4-code-compiled-under-9-0-uses-a-lot-more-memory-tp5756466p5756476.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 11:59:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B82AA3D7 for ; Tue, 30 Oct 2012 11:59:55 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 45FB58FC1E for ; Tue, 30 Oct 2012 11:59:55 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9UBxrVU033697 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 11:59:54 GMT Date: Tue, 30 Oct 2012 11:59:46 +0000 From: Karl Pielorz To: Erich Dollansky Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: In-Reply-To: <20121030182727.48f5e649@X220.ovitrap.com> References: <20121030182727.48f5e649@X220.ovitrap.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:59:55 -0000 --On 30 October 2012 18:27 +0700 Erich Dollansky wrote: > is it still the same compiler? Depends how you mean 'the same' - on the 6.4 system it shows: cc (GCC) 3.4.6 [FreeBSD] 20060305 And, on the 9.0-S it shows: cc (GCC) 4.2.1 20070831 patched [FreeBSD] So 'same' - but different versions. > I assume that it is a plain FreeBSD program without X. Yes. They are 'plain' programs - no X or anything. Now they've been running for an hour or so - they've gotten a little larger 552M/154M and 703M/75M. If it's not harmful I can live with it - it was just a bit of a surprise. -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 12:10:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92777CDE for ; Tue, 30 Oct 2012 12:10:33 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 230498FC16 for ; Tue, 30 Oct 2012 12:10:32 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9UCAUch035124 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 12:10:31 GMT Date: Tue, 30 Oct 2012 12:10:23 +0000 From: Karl Pielorz To: Jan Mikkelsen Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <233A9B7A1632D8758F378A74@MightyAtom.tdx.co.uk> In-Reply-To: <73635E29-D47C-4952-9958-1442970E7A4F@transactionware.com> References: <73635E29-D47C-4952-9958-1442970E7A4F@transactionware.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:10:33 -0000 --On 30 October 2012 22:59 +1100 Jan Mikkelsen wrote: >> -O2 -pthread -lc_r >> >> They're now compiled under 9.0-S with just: >> >> -O2 -pthread > > libc_r is a user mode implementation of pthreads, so there is one actual > kernel thread with a stack. You now have ~700 kernel threads on startup. > Per-thread stack allocation will be different, and you could quite easily > explain differences that way. That seems the most fitting explanation so far - aside from seeing if I can cut back on the number of threads, I presume there's no "issue" with having that many kicking around - the RES size is still quite 'small' (still waiting to see if anything is 'leaking') - and if ~700 threads happily ran under user mode pthreads - it should still perform at least 'similarly' with kernel threading? -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 12:06:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCAF0BA6 for ; Tue, 30 Oct 2012 12:06:30 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail3.transactionware.com [202.68.173.211]) by mx1.freebsd.org (Postfix) with SMTP id 0514E8FC14 for ; Tue, 30 Oct 2012 12:06:29 +0000 (UTC) Received: (qmail 77570 invoked by uid 907); 30 Oct 2012 11:59:46 -0000 Received: from eth222.nsw.adsl.internode.on.net (HELO [192.168.1.75]) (150.101.196.221) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Tue, 30 Oct 2012 22:59:46 +1100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Jan Mikkelsen In-Reply-To: Date: Tue, 30 Oct 2012 22:59:47 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <73635E29-D47C-4952-9958-1442970E7A4F@transactionware.com> References: To: Karl Pielorz X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 30 Oct 2012 12:24:44 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:06:30 -0000 Hi, On 30/10/2012, at 10:12 PM, Karl Pielorz wrote: >=20 > Hi All, >=20 > Can anyone think of any quick pointers as to why some code originally = written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes = up a *lot* more memory when running? >=20 > The code involved is a sendmail Milter, and a TCP server type program = (that runs up a large number of threads [~700] at startup). >=20 > Both were previously compiled with: >=20 > -O2 -pthread -lc_r >=20 > They're now compiled under 9.0-S with just: >=20 > -O2 -pthread libc_r is a user mode implementation of pthreads, so there is one actual = kernel thread with a stack. You now have ~700 kernel threads on startup. = Per-thread stack allocation will be different, and you could quite = easily explain differences that way. Regards, Jan. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 12:43:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BB4F93B for ; Tue, 30 Oct 2012 12:43:16 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id D4B618FC08 for ; Tue, 30 Oct 2012 12:43:15 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q9UCh8IU020907; Tue, 30 Oct 2012 06:43:13 -0600 Date: Tue, 30 Oct 2012 19:43:07 +0700 From: Erich Dollansky To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121030194307.57e5c5a3@X220.ovitrap.com> In-Reply-To: References: <20121030182727.48f5e649@X220.ovitrap.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:43:16 -0000 Hi, On Tue, 30 Oct 2012 11:59:46 +0000 Karl Pielorz wrote: > > > --On 30 October 2012 18:27 +0700 Erich Dollansky > wrote: > > > is it still the same compiler? > > Depends how you mean 'the same' - on the 6.4 system it shows: > > cc (GCC) 3.4.6 [FreeBSD] 20060305 > > And, on the 9.0-S it shows: > > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > > So 'same' - but different versions. > did you check the default data sizes? > > I assume that it is a plain FreeBSD program without X. > > Yes. They are 'plain' programs - no X or anything. > > Now they've been running for an hour or so - they've gotten a little > larger 552M/154M and 703M/75M. > > If it's not harmful I can live with it - it was just a bit of a > surprise. And a reason to spend more money on memory. Knowing the real reason would be better. I can understand your surprise. Erich From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 14:48:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8256D9D5 for ; Tue, 30 Oct 2012 14:48:16 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 804BD8FC17 for ; Tue, 30 Oct 2012 14:48:09 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q9UEm84F063212 for ; Tue, 30 Oct 2012 08:48:08 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q9UEljs7005594; Tue, 30 Oct 2012 08:47:45 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Ian Lepore To: Fabian Keil In-Reply-To: <20121030134614.1a42f0e3@fabiankeil.de> References: <20121030134614.1a42f0e3@fabiankeil.de> Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Oct 2012 08:47:45 -0600 Message-ID: <1351608465.1120.30.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:48:16 -0000 On Tue, 2012-10-30 at 13:46 +0100, Fabian Keil wrote: > Karl Pielorz wrote: > > > Can anyone think of any quick pointers as to why some code originally > > written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes > > up a *lot* more memory when running? > > 6.4 comes with phkmalloc while 9.0 uses jemalloc. Maybe you are > allocating memory in a way that is less space-efficiently handled by > jemalloc's default configuration. > > Fabian jemalloc is certainly the first thing that came to my mind. Does MALLOC_PRODUCTION need to be defined on a 9.0 system, or is that something that gets turned on automatically in an official release build? (I'm always working with non-release stuff so I'm not sure how that gets handled). -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 14:58:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 765ECD86 for ; Tue, 30 Oct 2012 14:58:28 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1D45F8FC0A for ; Tue, 30 Oct 2012 14:58:28 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TTDGx-0003IN-Nd for freebsd-hackers@freebsd.org; Tue, 30 Oct 2012 15:58:31 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Oct 2012 15:58:31 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Oct 2012 15:58:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Date: Tue, 30 Oct 2012 15:58:10 +0100 Lines: 47 Message-ID: References: <20121030134614.1a42f0e3@fabiankeil.de> <1351608465.1120.30.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C557084087D2E1B53E710D3" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: <1351608465.1120.30.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:58:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C557084087D2E1B53E710D3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30/10/2012 15:47, Ian Lepore wrote: > On Tue, 2012-10-30 at 13:46 +0100, Fabian Keil wrote: >> Karl Pielorz wrote: >> >>> Can anyone think of any quick pointers as to why some code originally= =20 >>> written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 tak= es >>> up a *lot* more memory when running? >> >> 6.4 comes with phkmalloc while 9.0 uses jemalloc. Maybe you are >> allocating memory in a way that is less space-efficiently handled by >> jemalloc's default configuration. >> >> Fabian >=20 > jemalloc is certainly the first thing that came to my mind. Does > MALLOC_PRODUCTION need to be defined on a 9.0 system, or is that > something that gets turned on automatically in an official release > build? (I'm always working with non-release stuff so I'm not sure how > that gets handled). It is turned on by default on -stable, by a commit from release engineers= =2E --------------enig0C557084087D2E1B53E710D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCP6wIACgkQ/QjVBj3/HSyT0QCfRZ+5AcJeSrKXtHv+VvmfsRst H0YAn0VCNK7CCNHVPVe9TIl4AP9wtzkV =TXsp -----END PGP SIGNATURE----- --------------enig0C557084087D2E1B53E710D3-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 15:26:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DE46C20 for ; Tue, 30 Oct 2012 15:26:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 09C838FC16 for ; Tue, 30 Oct 2012 15:26:02 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TTDUn-000860-Pn for freebsd-hackers@freebsd.org; Tue, 30 Oct 2012 17:12:49 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers@freebsd.org Subject: pxeboot slowness when run in vmware Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Oct 2012 17:12:49 +0200 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:26:03 -0000 hi, as soon as I 'initialize' a virtual disk via gpart, even if nothing is mounted, the pxeboot adds around 60s delay to show the boot menu, - I don't know if the delay is in boot or pxeboot. if I destroy the geom, the the boot menu appears inmediately. any insight? danny From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 16:56:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF32BC4B for ; Tue, 30 Oct 2012 16:56:28 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4763A8FC0A for ; Tue, 30 Oct 2012 16:56:27 +0000 (UTC) Received: from Octca64MkIV.tdx.co.uk (octa64.tdx.co.uk [62.13.130.232]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9UGuQU8057596 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 16:56:26 GMT Date: Tue, 30 Oct 2012 16:56:58 +0000 From: Karl Pielorz To: Erich Dollansky Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> In-Reply-To: <20121030194307.57e5c5a3@X220.ovitrap.com> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:56:28 -0000 --On 30 October 2012 19:43 +0700 Erich Dollansky wrote: >> Depends how you mean 'the same' - on the 6.4 system it shows: >> >> cc (GCC) 3.4.6 [FreeBSD] 20060305 >> >> And, on the 9.0-S it shows: >> >> cc (GCC) 4.2.1 20070831 patched [FreeBSD] >> >> So 'same' - but different versions. >> > did you check the default data sizes? How do you mean? >> Now they've been running for an hour or so - they've gotten a little >> larger 552M/154M and 703M/75M. >> >> If it's not harmful I can live with it - it was just a bit of a >> surprise. > > And a reason to spend more money on memory. Knowing the real reason > would be better. > > I can understand your surprise. Hehe, more 'concern' than surprise I guess now... The sendmail milter has grown to a SIZE/RES of 1045M / 454M under 9.0. The original 6.4 machine under heaver load (more connections) shows a SIZE/RES of 85M/52M. The TCP listener code is now showing a SIZE/REZ of 815M/80M under 9.0 with the original 6.4 box showing 44M/9.5M The 9.0 box says it has 185M active, 472M inactive, 693M wired, 543M buf, and 4554M free. At this stage I'm just a bit concerned that at least the milter code is going to grow, and grow - and die. I would think it would last over night so I'll see what the figures are in the morning. Thanks for the replies... -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 17:47:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E2D3146 for ; Tue, 30 Oct 2012 17:47:07 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9628FC16 for ; Tue, 30 Oct 2012 17:47:07 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id E3A801A3D9F; Tue, 30 Oct 2012 10:47:06 -0700 (PDT) Message-ID: <509012D3.5060705@mu.org> Date: Tue, 30 Oct 2012 10:48:03 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> In-Reply-To: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:47:07 -0000 Some suggestions here, jemalloc, kernel threads are good ones. Another issue may just be some change for default thread stack size. This would explain why the RESIDENT set is the same, but the VIRTUAL grew. -Alfred On 10/30/12 9:56 AM, Karl Pielorz wrote: > > > --On 30 October 2012 19:43 +0700 Erich Dollansky > wrote: > >>> Depends how you mean 'the same' - on the 6.4 system it shows: >>> >>> cc (GCC) 3.4.6 [FreeBSD] 20060305 >>> >>> And, on the 9.0-S it shows: >>> >>> cc (GCC) 4.2.1 20070831 patched [FreeBSD] >>> >>> So 'same' - but different versions. >>> >> did you check the default data sizes? > > How do you mean? > >>> Now they've been running for an hour or so - they've gotten a little >>> larger 552M/154M and 703M/75M. >>> >>> If it's not harmful I can live with it - it was just a bit of a >>> surprise. >> >> And a reason to spend more money on memory. Knowing the real reason >> would be better. >> >> I can understand your surprise. > > Hehe, more 'concern' than surprise I guess now... > > The sendmail milter has grown to a SIZE/RES of 1045M / 454M under 9.0. > The original 6.4 machine under heaver load (more connections) shows a > SIZE/RES of 85M/52M. > > The TCP listener code is now showing a SIZE/REZ of 815M/80M under 9.0 > with the original 6.4 box showing 44M/9.5M > > The 9.0 box says it has 185M active, 472M inactive, 693M wired, 543M > buf, and 4554M free. > > At this stage I'm just a bit concerned that at least the milter code > is going to grow, and grow - and die. > > I would think it would last over night so I'll see what the figures > are in the morning. > > Thanks for the replies... > > -Karl > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 17:51:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3007415 for ; Tue, 30 Oct 2012 17:51:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 245848FC17 for ; Tue, 30 Oct 2012 17:51:49 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id q9UHpcXB003367; Tue, 30 Oct 2012 19:51:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id q9UHpcM1003366; Tue, 30 Oct 2012 19:51:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 30 Oct 2012 19:51:38 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121030175138.GA73505@kib.kiev.ua> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cou6PmgoyP0+llr2" Content-Disposition: inline In-Reply-To: <509012D3.5060705@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:51:50 -0000 --Cou6PmgoyP0+llr2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 30, 2012 at 10:48:03AM -0700, Alfred Perlstein wrote: > Some suggestions here, jemalloc, kernel threads are good ones. >=20 > Another issue may just be some change for default thread stack size. =20 > This would explain why the RESIDENT set is the same, but the VIRTUAL grew. I suggest to take a look at where the actual memory goes. Start with procstat -v. >=20 > -Alfred >=20 > On 10/30/12 9:56 AM, Karl Pielorz wrote: > > > > > > --On 30 October 2012 19:43 +0700 Erich Dollansky=20 > > wrote: > > > >>> Depends how you mean 'the same' - on the 6.4 system it shows: > >>> > >>> cc (GCC) 3.4.6 [FreeBSD] 20060305 > >>> > >>> And, on the 9.0-S it shows: > >>> > >>> cc (GCC) 4.2.1 20070831 patched [FreeBSD] > >>> > >>> So 'same' - but different versions. > >>> > >> did you check the default data sizes? > > > > How do you mean? > > > >>> Now they've been running for an hour or so - they've gotten a little > >>> larger 552M/154M and 703M/75M. > >>> > >>> If it's not harmful I can live with it - it was just a bit of a > >>> surprise. > >> > >> And a reason to spend more money on memory. Knowing the real reason > >> would be better. > >> > >> I can understand your surprise. > > > > Hehe, more 'concern' than surprise I guess now... > > > > The sendmail milter has grown to a SIZE/RES of 1045M / 454M under 9.0.= =20 > > The original 6.4 machine under heaver load (more connections) shows a= =20 > > SIZE/RES of 85M/52M. > > > > The TCP listener code is now showing a SIZE/REZ of 815M/80M under 9.0= =20 > > with the original 6.4 box showing 44M/9.5M > > > > The 9.0 box says it has 185M active, 472M inactive, 693M wired, 543M=20 > > buf, and 4554M free. > > > > At this stage I'm just a bit concerned that at least the milter code=20 > > is going to grow, and grow - and die. > > > > I would think it would last over night so I'll see what the figures=20 > > are in the morning. > > > > Thanks for the replies... > > > > -Karl > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to=20 > > "freebsd-hackers-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --Cou6PmgoyP0+llr2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCQE6kACgkQC3+MBN1Mb4hzbQCgpQizTWFRrtVoJatrAZgHqY7O sQ8AoJgEduJnT2YqEZEGhdMtU9MXEV5j =Yh67 -----END PGP SIGNATURE----- --Cou6PmgoyP0+llr2-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 09:49:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C101B1E2 for ; Wed, 31 Oct 2012 09:49:33 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 50F408FC16 for ; Wed, 31 Oct 2012 09:49:32 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9V9nVLN084995 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 09:49:31 GMT Date: Wed, 31 Oct 2012 09:49:21 +0000 From: Karl Pielorz To: Konstantin Belousov , Alfred Perlstein Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: In-Reply-To: <20121030175138.GA73505@kib.kiev.ua> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 09:49:33 -0000 --On 30 October 2012 19:51 +0200 Konstantin Belousov wrote: > I suggest to take a look at where the actual memory goes. > > Start with procstat -v. Ok, running that for the milter PID I get seem to be able to see smallish chunks used for things like 'libmilter.so', and 'libthr.so' / 'libc.so' - e.g. 2010 0x400000 0x413000 r-x 19 0 1 0 CN-- vn /usr/local/sbin/milter 2010 0x613000 0x800000 rw- 15 0 1 0 ---- df 2010 0x800613000 0x80062b000 r-x 24 0 97 0 CN-- vn /libexec/ld-elf.so.1 2010 0x80062b000 0x800634000 rw- 9 0 1 0 ---- df 2010 0x800634000 0x80065f000 rw- 33 0 1 0 ---- df 2010 0x80082b000 0x80082d000 rw- 2 0 1 0 ---- df 2010 0x80082d000 0x800839000 r-x 12 12 2 1 CN-- vn /usr/lib/libmilter.so.5 2010 0x800839000 0x800a38000 --- 0 0 1 0 ---- df 2010 0x800a38000 0x800a39000 rw- 1 0 1 0 C--- vn /usr/lib/libmilter.so.5 2010 0x800a39000 0x800a3c000 rw- 0 0 0 0 ---- -- Then there's a bunch of 'large' blocks e.g.. PID START END PRT RES PRES REF SHD FL TP PATH 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 ---- df 2010 0x802800000 0x803400000 rw- 1880 0 1 0 ---- df 2010 0x803400000 0x803800000 rw- 920 0 1 0 ---- df 2010 0x803800000 0x804000000 rw- 865 0 1 0 ---- df 2010 0x804000000 0x804400000 rw- 1024 0 4 0 ---- df 2010 0x804400000 0x804c00000 rw- 627 0 1 0 ---- df 2010 0x804c00000 0x805000000 rw- 1021 0 4 0 ---- df Then lots of 'little' blocks, 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D df 2010 0x7ffff0362000 0x7ffff0382000 rw- 16 0 1 0 ---D df 2010 0x7ffff0563000 0x7ffff0583000 rw- 16 0 1 0 ---D df 2010 0x7ffff0764000 0x7ffff0784000 rw- 16 0 1 0 ---D df 2010 0x7ffff0965000 0x7ffff0985000 rw- 16 0 1 0 ---D df 2010 0x7ffff0b66000 0x7ffff0b86000 rw- 16 0 1 0 ---D df 2010 0x7ffff0d67000 0x7ffff0d87000 rw- 16 0 1 0 ---D df 2010 0x7ffff0f68000 0x7ffff0f88000 rw- 16 0 1 0 ---D df 2010 0x7ffff1169000 0x7ffff1189000 rw- 16 0 1 0 ---D df The memory usage figures seem to have 'stabilized' now - SIZE/RES seem to track around 9 times the size of the 6.4 system, for a comparative load. We can probably live with this (as they have come back down overnight as load fell off) - i.e. they don't appear to be continuously growing (the binaries were heavily profiled under 6.x and found to have no internal leaks). -Karl From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 09:14:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5997BA38 for ; Wed, 31 Oct 2012 09:14:06 +0000 (UTC) (envelope-from vagner@bsdway.ru) Received: from bsdway.ru (bsdway.ru [62.109.17.46]) by mx1.freebsd.org (Postfix) with ESMTP id BDCAD8FC08 for ; Wed, 31 Oct 2012 09:14:04 +0000 (UTC) Received: from localhost (off-180.addr.fotocdn.net [193.105.179.180]) (authenticated bits=0) by bsdway.ru (8.14.4/8.14.4) with ESMTP id q9V9E2dU011188 for ; Wed, 31 Oct 2012 12:14:02 +0300 (MSK) (envelope-from vagner@bsdway.ru) Date: Wed, 31 Oct 2012 13:14:02 +0400 From: Vagner To: FreeBSD hackers Mail List Subject: Management for VM objects Message-ID: <20121031091402.GA7070@vagner-wrk.bsdway.ru> Mail-Followup-To: FreeBSD hackers Mail List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bsdway.ru [62.109.17.46]); Wed, 31 Oct 2012 12:14:02 +0300 (MSK) X-Mailman-Approved-At: Wed, 31 Oct 2012 11:02:38 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 09:14:06 -0000 Hi! This questions about Inactive queue and Swap layer in VM management system at FreeBSD. For test, i running dd (for put ufs cache to Inactive), and i get this: 1132580 wire 896796 act 5583964 inact 281852 cache 112252 free 836960 buf in swap: 20M It is good. Lets start run programm like: typedef char * pchar; pchar a[1024*1024*4]; for(size_t i = 0; i < 1024*1024*2; i++) { a[i] = (pchar)malloc(1024); if(a[i]) *(a[i]) = 'F'; } Get this: 1156420 wire 3070196 act 3465316 inact 206352 cache 109160 free 836960 buf in swap: 20M After i call free() pages put to free. But, why condition is not satisfied from this page: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/freeing-pages.html? My durty pages don't written to their backing store before being reusable. I don't understeand this:( And... How can i known what memory page in Inactive owns UFS cache? Thanks -- Respectfully, Stanislav Putrya System administrator FotoStrana.Ru Ltd. ICQ IM: 328585847 Jabber-GoogleTalk: root.vagner mob.phone SPB: +79215788755 mob.phone RND: +79525600664 email: vagner@bsdway.ru email: putrya@playform.ru email: root.vagner@gmail.com site: bsdway.ru site: fotostrana.ru ---------------------------------------- ( ) ASCII ribbon campaign X - against HTML, vCards and / \ - proprietary attachments in e-mail From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 14:06:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C9861E0 for ; Wed, 31 Oct 2012 14:06:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id CFE7C8FC12 for ; Wed, 31 Oct 2012 14:06:42 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id q9VE6U64023084; Wed, 31 Oct 2012 16:06:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id q9VE6U0n023083; Wed, 31 Oct 2012 16:06:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 31 Oct 2012 16:06:30 +0200 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121031140630.GE73505@kib.kiev.ua> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6nSyB+bcl/pT7+kx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:06:43 -0000 --6nSyB+bcl/pT7+kx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 09:49:21AM +0000, Karl Pielorz wrote: >=20 > --On 30 October 2012 19:51 +0200 Konstantin Belousov =20 > wrote: >=20 > > I suggest to take a look at where the actual memory goes. > > > > Start with procstat -v. >=20 > Ok, running that for the milter PID I get seem to be able to see smallish= =20 > chunks used for things like 'libmilter.so', and 'libthr.so' / 'libc.so' -= =20 > e.g. Since you neglected to provide the verbatim output of procstat, nothing conclusive can be said. Obviously, you can make an investigation on your own. >=20 > 2010 0x400000 0x413000 r-x 19 0 1 0 CN-- vn= =20 > /usr/local/sbin/milter > 2010 0x613000 0x800000 rw- 15 0 1 0 ---- df > 2010 0x800613000 0x80062b000 r-x 24 0 97 0 CN-- vn= =20 > /libexec/ld-elf.so.1 > 2010 0x80062b000 0x800634000 rw- 9 0 1 0 ---- df > 2010 0x800634000 0x80065f000 rw- 33 0 1 0 ---- df > 2010 0x80082b000 0x80082d000 rw- 2 0 1 0 ---- df > 2010 0x80082d000 0x800839000 r-x 12 12 2 1 CN-- vn= =20 > /usr/lib/libmilter.so.5 > 2010 0x800839000 0x800a38000 --- 0 0 1 0 ---- df > 2010 0x800a38000 0x800a39000 rw- 1 0 1 0 C--- vn= =20 > /usr/lib/libmilter.so.5 > 2010 0x800a39000 0x800a3c000 rw- 0 0 0 0 ---- -- >=20 > Then there's a bunch of 'large' blocks e.g.. >=20 > PID START END PRT RES PRES REF SHD FL TP P= ATH > 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 ---- df > 2010 0x802800000 0x803400000 rw- 1880 0 1 0 ---- df > 2010 0x803400000 0x803800000 rw- 920 0 1 0 ---- df > 2010 0x803800000 0x804000000 rw- 865 0 1 0 ---- df > 2010 0x804000000 0x804400000 rw- 1024 0 4 0 ---- df > 2010 0x804400000 0x804c00000 rw- 627 0 1 0 ---- df > 2010 0x804c00000 0x805000000 rw- 1021 0 4 0 ---- df Most likely, these are malloc arenas. >=20 > Then lots of 'little' blocks, >=20 > 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0362000 0x7ffff0382000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0563000 0x7ffff0583000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0764000 0x7ffff0784000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0965000 0x7ffff0985000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0b66000 0x7ffff0b86000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0d67000 0x7ffff0d87000 rw- 16 0 1 0 ---D df > 2010 0x7ffff0f68000 0x7ffff0f88000 rw- 16 0 1 0 ---D df > 2010 0x7ffff1169000 0x7ffff1189000 rw- 16 0 1 0 ---D df And those are thread stacks. >=20 >=20 > The memory usage figures seem to have 'stabilized' now - SIZE/RES seem to= =20 > track around 9 times the size of the 6.4 system, for a comparative load. >=20 > We can probably live with this (as they have come back down overnight as= =20 > load fell off) - i.e. they don't appear to be continuously growing (the= =20 > binaries were heavily profiled under 6.x and found to have no internal=20 > leaks). >=20 > -Karl --6nSyB+bcl/pT7+kx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCRMGYACgkQC3+MBN1Mb4hINACfQFyivGuLWOlvZARD8wWFpZVV 7ooAnjfFjvPOH0fMVy3RcIxxQ5dMHpoM =uMXA -----END PGP SIGNATURE----- --6nSyB+bcl/pT7+kx-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 14:44:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45ECC880 for ; Wed, 31 Oct 2012 14:44:25 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id C43088FC12 for ; Wed, 31 Oct 2012 14:44:24 +0000 (UTC) Received: from MightyAtom.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id q9VEiG7A009566 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 14:44:16 GMT Date: Wed, 31 Oct 2012 14:44:05 +0000 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: In-Reply-To: <20121031140630.GE73505@kib.kiev.ua> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:44:25 -0000 --On 31 October 2012 16:06 +0200 Konstantin Belousov wrote: > Since you neglected to provide the verbatim output of procstat, nothing > conclusive can be said. Obviously, you can make an investigation on your > own. Sorry - when I ran it this morning the output was several hundred lines - I didn't want to post all of that to the list 99% of the lines are very similar. I can email it you off-list if having the whole lot will help? >> Then there's a bunch of 'large' blocks e.g.. >> >> PID START END PRT RES PRES REF SHD FL TP >> PATH 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 >> ---- df 2010 0x802800000 0x803400000 rw- 1880 0 1 0 > > Most likely, these are malloc arenas. Ok, that's the heaviest usage. >> Then lots of 'little' blocks, >> >> 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D df > > And those are thread stacks. Ok, lots of those (lots of threads going on) - but they're all pretty small. My code only has a single call to malloc, which allocates around 20k per thread. Obviously there's other libraries and stuff running with the code - so would I be correct in guessing that they are more than likely for most of these large blocks? -Karl From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 14:53:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3096CB2 for ; Wed, 31 Oct 2012 14:53:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1825B8FC08 for ; Wed, 31 Oct 2012 14:53:49 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id q9VErhwC027503; Wed, 31 Oct 2012 16:53:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id q9VErhtj027502; Wed, 31 Oct 2012 16:53:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 31 Oct 2012 16:53:43 +0200 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121031145343.GI73505@kib.kiev.ua> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Guq+xBHXhbnAFmh4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:53:50 -0000 --Guq+xBHXhbnAFmh4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 02:44:05PM +0000, Karl Pielorz wrote: >=20 >=20 > --On 31 October 2012 16:06 +0200 Konstantin Belousov =20 > wrote: >=20 > > Since you neglected to provide the verbatim output of procstat, nothing > > conclusive can be said. Obviously, you can make an investigation on your > > own. >=20 > Sorry - when I ran it this morning the output was several hundred lines -= I=20 > didn't want to post all of that to the list 99% of the lines are very=20 > similar. I can email it you off-list if having the whole lot will help? Just put is somewhere on http server and provide the URL. >=20 > >> Then there's a bunch of 'large' blocks e.g.. > >> > >> PID START END PRT RES PRES REF SHD FL TP > >> PATH 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 > >> ---- df 2010 0x802800000 0x803400000 rw- 1880 0 1 = 0 > > > > Most likely, these are malloc arenas. >=20 > Ok, that's the heaviest usage. So it is, most likely, either app doing more malloc allocations, or the difference is due to more aggressive jemalloc behaviour. If this indeed bothers you, you could try to use plug-in replacements for malloc. They are usually LD_PRELOAD'ed, search the ports. But I would not bother. >=20 > >> Then lots of 'little' blocks, > >> > >> 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D = df > > > > And those are thread stacks. >=20 > Ok, lots of those (lots of threads going on) - but they're all pretty sma= ll. >=20 > My code only has a single call to malloc, which allocates around 20k per= =20 > thread. You should look both at the virtual address space allocation for the block, which is specified by (start, end), and at the actual resident page count. >=20 > Obviously there's other libraries and stuff running with the code - so=20 > would I be correct in guessing that they are more than likely for most of= =20 > these large blocks? No idea. --Guq+xBHXhbnAFmh4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCRO3YACgkQC3+MBN1Mb4i5igCgvDPzvpZt7hl6jyrKSons+/Qn Px4An0/cclUcbodTcwaDnmRfGhCWQzPw =DYLE -----END PGP SIGNATURE----- --Guq+xBHXhbnAFmh4-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 17:27:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDA328AF for ; Wed, 31 Oct 2012 17:27:07 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id AF7A58FC14 for ; Wed, 31 Oct 2012 17:27:07 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [172.17.17.101]) by email2.allantgroup.com (8.14.5/8.14.5) with ESMTP id q9VHLbbN023662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 12:21:37 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id q9VHLbja023951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 12:21:37 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id q9VHLa2u023950; Wed, 31 Oct 2012 12:21:36 -0500 (CDT) (envelope-from dan) Date: Wed, 31 Oct 2012 12:21:36 -0500 From: Dan Nelson To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121031172136.GB21003@dan.emsphone.com> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.3-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (email2.allantgroup.com [172.17.19.78]); Wed, 31 Oct 2012 12:21:38 -0500 (CDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on email2.allantgroup.com X-Scanned-By: MIMEDefang 2.73 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:27:08 -0000 In the last episode (Oct 31), Karl Pielorz said: > --On 31 October 2012 16:06 +0200 Konstantin Belousov wrote: > > Since you neglected to provide the verbatim output of procstat, nothing > > conclusive can be said. Obviously, you can make an investigation on > > your own. > > Sorry - when I ran it this morning the output was several hundred lines - > I didn't want to post all of that to the list 99% of the lines are very > similar. I can email it you off-list if having the whole lot will help? > > >> Then there's a bunch of 'large' blocks e.g.. > >> > >> PID START END PRT RES PRES REF SHD FL TP > >> PATH 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 > >> ---- df 2010 0x802800000 0x803400000 rw- 1880 0 1 0 > > > > Most likely, these are malloc arenas. > > Ok, that's the heaviest usage. > > >> Then lots of 'little' blocks, > >> > >> 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D df > > > > And those are thread stacks. > > Ok, lots of those (lots of threads going on) - but they're all pretty > small. > > My code only has a single call to malloc, which allocates around 20k per > thread. > > Obviously there's other libraries and stuff running with the code - so > would I be correct in guessing that they are more than likely for most of > these large blocks? Note that libmilter may do a lot of mallocs on its own, especially if you are examining the message body. There are also jemalloc tuning options that may lower total meory usage if you are using a lot of threads. I'd take a look at the G and R flags first. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 17:55:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B7DA116 for ; Wed, 31 Oct 2012 17:55:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 43FAE8FC16 for ; Wed, 31 Oct 2012 17:55:59 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1228030pad.13 for ; Wed, 31 Oct 2012 10:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QMIMH2q1kErvOEXcr5XPncQKpumdM9OGZnqLyfSX5Is=; b=IjIiiYlA9akiR+yT3xRKPdvVE9pQpDfU9mXQzkxmxyh6DO9DpEVScNalHexNmUVz5h gJF3Z1WGI+6JYBXWVXlQ6E382QwK9xz4CJWaUU+Q7edi/tqUO9ywFVvZ+KFXnGEEVj7Z ugSYj+ewliID5k+0DvJGc1HO5zlkxbqi2R/ZU9/SHPJc7MiHwB2y9Mvxshu6gbMfZw2H 5HsodOm0ZYih3DPj8hwWgNCezNHdsmBSGxn5miljqJUjnf8Alm6wBb+/HZ383e9B4Lk6 zHkF+x5qpOvvYXEuWI5iZw8uQ3LX88vncjKF+DekdcWZUXQqu+lTaOWiipPg0WTZ9Z0B bd/w== MIME-Version: 1.0 Received: by 10.68.232.131 with SMTP id to3mr115716709pbc.58.1351706158831; Wed, 31 Oct 2012 10:55:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 31 Oct 2012 10:55:58 -0700 (PDT) In-Reply-To: <20121031172136.GB21003@dan.emsphone.com> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> Date: Wed, 31 Oct 2012 10:55:58 -0700 X-Google-Sender-Auth: RBj4BXLECIgIPhepeXdH11SDyMU Message-ID: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Adrian Chadd To: Dan Nelson Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Alfred Perlstein , Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:55:59 -0000 .. isn't the default thread stack size now really quite large? Like one megabyte large? adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 18:21:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B533F13C; Wed, 31 Oct 2012 18:21:12 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id A40858FC0C; Wed, 31 Oct 2012 18:21:05 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q9VIKwDH011164; Wed, 31 Oct 2012 12:20:58 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q9VIKtnR006748; Wed, 31 Oct 2012 12:20:55 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Oct 2012 12:20:55 -0600 Message-ID: <1351707655.1120.94.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Alfred Perlstein , Dan Nelson , Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:21:12 -0000 On Wed, 2012-10-31 at 10:55 -0700, Adrian Chadd wrote: > .. isn't the default thread stack size now really quite large? > > Like one megabyte large? That would explain a larger VSZ but the original post mentions that both virtual and resident sizes have grown by almost an order of magnitude. I think the same is true of the jemalloc aspect -- its design makes it use more virtual address space than phkmalloc when you've got lots of threads, but that shouldn't make it use so much more physical memory. I'm not positive of that, but I did notice when we upgraded from 6.x to 8.2 at work, our apps that have many dozens of threads use more virtual space, but not dramatically as much more physical memory as in the OP's case. I think there are some things we should be investigating about the growth of memory usage. I just noticed this: Freebsd 6.2 on an arm processor: 369 root 1 8 -88 1752K 748K nanslp 3:00 0.00% watchdogd Freebsd 10.0 on the same system: 367 root 1 -52 r0 10232K 10160K nanslp 10:04 0.00% watchdogd The 10.0 system is built with MALLOC_PRODUCTION (without that defined the system won't even boot, it only has 64MB of ram). That's a crazy amount of growth for a relatively simple daemon. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 18:52:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6A0BD56 for ; Wed, 31 Oct 2012 18:52:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8C82B8FC08 for ; Wed, 31 Oct 2012 18:52:07 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so830873dad.13 for ; Wed, 31 Oct 2012 11:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sYKknIm4TC3vQ4OunqnLRXTJ8Qj9RwL+2yPfSF3bq3g=; b=eLrERvJjsm1rBjo5LZyzx7elZzg+GwifsB9XwTP+U68vrdykuNoElFBoDGFB6GuFJ9 DdwLFiwIgtEcP7hSVFrTZOK8Rzx5+435G7HvY3avtM0BF5ZMnfE9kn4FclOv6CQBcPcT 25CJ1Ff88q3R+HnKxUnJJyQCkW8x5KYVLHMTN4v9i6k2boEEmtg1kjQm1rgAmwrOnrfd ZBwECo/tICC32vJhghrxubb9cojm5to/Z/cdZiBCAgxlTAE6GJAXFaifSDtkYOA5117p oTi8HfDYYCchX2FAR6A7ICjF2xxokvs46YEht9AAWyYQCbWBtbuElFUHHefD6navDW+p S/mg== MIME-Version: 1.0 Received: by 10.66.79.168 with SMTP id k8mr104192458pax.12.1351709527012; Wed, 31 Oct 2012 11:52:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 31 Oct 2012 11:52:06 -0700 (PDT) In-Reply-To: <1351707655.1120.94.camel@revolution.hippie.lan> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> Date: Wed, 31 Oct 2012 11:52:06 -0700 X-Google-Sender-Auth: 0K7o42qGQ3Q5S7hlypZ3dQA1iGA Message-ID: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Alfred Perlstein , Dan Nelson , Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:52:07 -0000 On 31 October 2012 11:20, Ian Lepore wrote: > I think there are some things we should be investigating about the > growth of memory usage. I just noticed this: > > Freebsd 6.2 on an arm processor: > > 369 root 1 8 -88 1752K 748K nanslp 3:00 0.00% watchdogd > > Freebsd 10.0 on the same system: > > 367 root 1 -52 r0 10232K 10160K nanslp 10:04 0.00% watchdogd > > The 10.0 system is built with MALLOC_PRODUCTION (without that defined > the system won't even boot, it only has 64MB of ram). That's a crazy > amount of growth for a relatively simple daemon. Would you please, _please_ do some digging into this? It's quite possible there's something in the libraries that are allocating some memory upon first call invocation - yes, that's jemalloc, but it could also be other things like stdio. We really, really need to fix this userland bloat; it's terribly ridiculous at this point. There's no reason a watchdog daemon should take 10megabytes of RAM. Thanks, Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 19:06:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 499DF4D4 for ; Wed, 31 Oct 2012 19:06:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id B78D58FC18 for ; Wed, 31 Oct 2012 19:06:31 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id q9VJ6NsF052420; Wed, 31 Oct 2012 21:06:23 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id q9VJ6NBS052419; Wed, 31 Oct 2012 21:06:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 31 Oct 2012 21:06:23 +0200 From: Konstantin Belousov To: Adrian Chadd Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121031190623.GL73505@kib.kiev.ua> References: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XK4NhNJ9GVfup2vH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Ian Lepore , freebsd-hackers@freebsd.org, Alfred Perlstein , Dan Nelson , Karl Pielorz , Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 19:06:32 -0000 --XK4NhNJ9GVfup2vH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 11:52:06AM -0700, Adrian Chadd wrote: > On 31 October 2012 11:20, Ian Lepore wrot= e: > > I think there are some things we should be investigating about the > > growth of memory usage. I just noticed this: > > > > Freebsd 6.2 on an arm processor: > > > > 369 root 1 8 -88 1752K 748K nanslp 3:00 0.00% watchdogd > > > > Freebsd 10.0 on the same system: > > > > 367 root 1 -52 r0 10232K 10160K nanslp 10:04 0.00% watchdogd > > > > The 10.0 system is built with MALLOC_PRODUCTION (without that defined > > the system won't even boot, it only has 64MB of ram). That's a crazy > > amount of growth for a relatively simple daemon. >=20 > Would you please, _please_ do some digging into this? >=20 > It's quite possible there's something in the libraries that are > allocating some memory upon first call invocation - yes, that's > jemalloc, but it could also be other things like stdio. >=20 > We really, really need to fix this userland bloat; it's terribly > ridiculous at this point. There's no reason a watchdog daemon should > take 10megabytes of RAM. Watchdogd was recently changed to mlock its memory. This is the cause of the RSS increase. If not wired, swapout might cause a delay of the next pat, leading to panic. --XK4NhNJ9GVfup2vH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCRdq4ACgkQC3+MBN1Mb4jpgACgqDkm39SLQjKbYaWMWR2O9eqa 8OYAn3RQ91dC27+Vfx3Q0UGiJ5cAGSdH =pA/r -----END PGP SIGNATURE----- --XK4NhNJ9GVfup2vH-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 19:58:26 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 594C6498 for ; Wed, 31 Oct 2012 19:58:26 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9998FC0C for ; Wed, 31 Oct 2012 19:58:25 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 0615B1A3CB6 for ; Wed, 31 Oct 2012 12:58:19 -0700 (PDT) Message-ID: <509182DA.8070303@mu.org> Date: Wed, 31 Oct 2012 12:58:18 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: hackers@freebsd.org Subject: make -jN buildworld on < 512MB ram Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 19:58:26 -0000 It seems like the new compiler likes to get up to ~200+MB resident when building some basic things in our tree. Unfortunately this causes smaller machines (VMs) to take days because of swap thrashing. Doesn't our make(1) have some stuff to mitigate this? I would expect it to be a bit smarter about detecting the number of swaps/pages/faults of its children and taking into account the machine's total ram before forking off new processes. I know gmake has some algorithms, although last I checked they were very naive and didn't work well. Any ideas? I mean a really simple algorithm could be devised that would be better than what we appear to have (which is nothing). Even if an algorithm can't be come up with, why not something just to throttle the max number of c++/g++ processes thrown out. Maybe I'm missing a trick I can pull off with some make.conf knobs? Idk, summer of code idea? Anyone mentoring someone they want to have a look at this? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 20:24:20 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D183BAFB for ; Wed, 31 Oct 2012 20:24:20 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 938428FC0A for ; Wed, 31 Oct 2012 20:24:20 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2358064oag.13 for ; Wed, 31 Oct 2012 13:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bJvTpIOjy+glawCt6Cg+vfLk8ebS7ksCivMjR0tpWck=; b=FyVH7Jba8R9pFz6/fFk34EN8uCewGSxV0c9Th8Wp1KAnTi7AXm8n7ZZiQiDJwkdRC0 Jtsv9xjxdxUtHREXKXCfkVLFlx4grjpUwWjEutJCv3sIIVYGcLgW4dTjlX24vDBdyvnZ c7VDhQISYOZHzQTn6T0+XtArskbzHOJ/R986BGvtRChtcOIjLS+qM5+p+cznD65QhExj /ekUD8dP79SNdxU3sfGQwISQ6eyPXwKMYxlCFL0b5dV1RTTMhcKI23QI3WtUxxx6S+s2 qmx1mEskKwZPrwXLdhwIscg9ARBY36hG+B8h4sJHLR59VHZH1hUa+qofpoWA23AtW6R1 vyew== MIME-Version: 1.0 Received: by 10.182.150.34 with SMTP id uf2mr31932678obb.66.1351715059841; Wed, 31 Oct 2012 13:24:19 -0700 (PDT) Received: by 10.76.143.33 with HTTP; Wed, 31 Oct 2012 13:24:19 -0700 (PDT) In-Reply-To: <509182DA.8070303@mu.org> References: <509182DA.8070303@mu.org> Date: Wed, 31 Oct 2012 13:24:19 -0700 Message-ID: Subject: Re: make -jN buildworld on < 512MB ram From: Garrett Cooper To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:24:20 -0000 On Wed, Oct 31, 2012 at 12:58 PM, Alfred Perlstein wrote: > It seems like the new compiler likes to get up to ~200+MB resident when > building some basic things in our tree. > > Unfortunately this causes smaller machines (VMs) to take days because of > swap thrashing. > > Doesn't our make(1) have some stuff to mitigate this? I would expect it to > be a bit smarter about detecting the number of swaps/pages/faults of its > children and taking into account the machine's total ram before forking off > new processes. I know gmake has some algorithms, although last I checked > they were very naive and didn't work well. > > Any ideas? I mean a really simple algorithm could be devised that would be > better than what we appear to have (which is nothing). > > Even if an algorithm can't be come up with, why not something just to > throttle the max number of c++/g++ processes thrown out. Maybe I'm missing > a trick I can pull off with some make.conf knobs? > > Idk, summer of code idea? Anyone mentoring someone they want to have a look > at this? FreeBSD make/bmake doesn't, but gmake sure does with --load [1]! I would ask sjg@ to be absolutely sure, but I don't see any getrlimit/setrlimit calls around the code, apart from RLIMIT_NOFILE. For now you have to tune your number of jobs appropriately.. HTH, -Garrett PS I feel your pain because I have a number of FreeBSD VMs with <=2GB RAM. 1. http://www.gnu.org/software/make/manual/make.html#index-g_t_0040code_007b_002d_002dload_002daverage_007d-746 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 20:37:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 886C3272; Wed, 31 Oct 2012 20:37:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3032D8FC08; Wed, 31 Oct 2012 20:37:16 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so2359196obb.13 for ; Wed, 31 Oct 2012 13:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a9SkzuXNK/nvUzxz/CE4KNZz8btbE+5hMwrGNzaMqx4=; b=db6cEbLELoZV6zgiz7Lug4Dm2dxis1nd6v826G0SAf1wUs4aOL50/3t8ZXA0+NfdLv er6KkmSjahX9Ums7tRsxlcDVaSYt8IEL2C/AWtaZhol6rMYOn/+kAeR8InEcI6KEYE4O pQCb5idSoINdu85F4TJJF60+J9XLr+7zCF1MVtvBAW/8+jKQx30DB/Jw9UfAEjW6I5yg 2TXTfiKjNCEsiZvKiZYyDir2IwFruL4cat4bFXEWt+OofKhq49vBlYl8bQWvyDGB1QTP lqmkEVdqguX3LnvL29qpGTFnMj5tMPegUJCTQy9WK15l4gBbJNRXrpnVd1QEDkUHGh0K F/8A== MIME-Version: 1.0 Received: by 10.60.169.170 with SMTP id af10mr32870616oec.17.1351715836594; Wed, 31 Oct 2012 13:37:16 -0700 (PDT) Received: by 10.76.143.33 with HTTP; Wed, 31 Oct 2012 13:37:16 -0700 (PDT) In-Reply-To: <20121031190623.GL73505@kib.kiev.ua> References: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> <20121031190623.GL73505@kib.kiev.ua> Date: Wed, 31 Oct 2012 13:37:16 -0700 Message-ID: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Garrett Cooper To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Adrian Chadd , freebsd-hackers@freebsd.org, Alfred Perlstein , Dan Nelson , Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:37:17 -0000 On Wed, Oct 31, 2012 at 12:06 PM, Konstantin Belousov wrote: ... > If not wired, swapout might cause a delay of the next pat, leading to > panic. Yes. We need to write microbenchmarks and do more careful analysis to figure out where and why things have grown. Maybe a mock daemon and application (single and multithreaded) would be a good start? There are some example programs in the open_posix_testsuite (see LTP) that might be good for at least getting non-daemon apps that use pthreads that can be used for instrumenting where and why things have changed. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 20:38:42 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2168B36A for ; Wed, 31 Oct 2012 20:38:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D8B758FC0A for ; Wed, 31 Oct 2012 20:38:41 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1336871pbb.13 for ; Wed, 31 Oct 2012 13:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qls3MVECgHc6yb7dvS5CHpyEQCfMuC1h1liq+uh8BGk=; b=q+m7Ux5+nT9+nzOg2QbqluFhyqzRRLrvDj85G1BvHY+XoHF3KwBtePbWtv0M1E/liM wSd5Vuq2FQNunsUkWI2OrklNI/7RpVeoEA1nO6a+8iVIa2+D3IANqNYt8katgI0vdBZN K0NTxhlUnlaZ6sOvqy2GiQj5OP10sC6gOM0dKdnzOvkoFFh2XHoq0MeCpm4jG4HEWKHx W/IGWM3ZgXoar5JH1cAzpulS310K8DgRD0oTqhj6zxYDpQF9XohySrrbPt+TBKWsiBax qI0Jc5ae6qxd22fpYOQuT6U6JOpHPD7x8gttEgJYK9NGazaF80yoHHwdDiNjHTfqpS6p K34w== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr12024592pbc.69.1351715921526; Wed, 31 Oct 2012 13:38:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 31 Oct 2012 13:38:41 -0700 (PDT) In-Reply-To: <20121031190623.GL73505@kib.kiev.ua> References: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> <20121031190623.GL73505@kib.kiev.ua> Date: Wed, 31 Oct 2012 13:38:41 -0700 X-Google-Sender-Auth: Tv2merczzF9pWMkiFRd64T_dEIo Message-ID: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Alfred Perlstein , Dan Nelson , Karl Pielorz , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:38:42 -0000 On 31 October 2012 12:06, Konstantin Belousov wrote: > Watchdogd was recently changed to mlock its memory. This is the cause > of the RSS increase. > > If not wired, swapout might cause a delay of the next pat, leading to > panic. Right, but look at the virtual size of the 6.4 process. It's not 10 megabytes at all. Even if you wired all of that into memory, it wouldn't be 10 megabytes. Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 20:42:03 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20176518 for ; Wed, 31 Oct 2012 20:42:03 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 894898FC0C for ; Wed, 31 Oct 2012 20:42:01 +0000 (UTC) Received: from server.rulingia.com (c220-239-241-202.belrs5.nsw.optusnet.com.au [220.239.241.202]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q9VKfwYL037281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Nov 2012 07:41:58 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q9VKfqVF039592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2012 07:41:52 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q9VKfq1W039591; Thu, 1 Nov 2012 07:41:52 +1100 (EST) (envelope-from peter) Date: Thu, 1 Nov 2012 07:41:52 +1100 From: Peter Jeremy To: Alfred Perlstein Subject: Re: make -jN buildworld on < 512MB ram Message-ID: <20121031204152.GK3309@server.rulingia.com> References: <509182DA.8070303@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: <509182DA.8070303@mu.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:42:03 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Oct-31 12:58:18 -0700, Alfred Perlstein wrote: >It seems like the new compiler likes to get up to ~200+MB resident when=20 >building some basic things in our tree. The killer I found was the ctfmerge(1) on the kernel - which exceeds ~400MB on i386. Under low RAM, that fails _without_ reporting any errors back to make(1), resulting in a corrupt new kernel (it booted but had virtually no devices so it couldn't find root). >Doesn't our make(1) have some stuff to mitigate this? I would expect it= =20 >to be a bit smarter about detecting the number of swaps/pages/faults of=20 >its children and taking into account the machine's total ram before=20 >forking off new processes. The difficulty I see is that the make process can't tell anything about the memory requirements of the pipeline it is about to spawn. As a rule of thumb, C++ needs more memory than C but that depends on what is being compiled - I have a machine-generated C program that makes gcc bloat to ~12GB. >Any ideas? I mean a really simple algorithm could be devised that would= =20 >be better than what we appear to have (which is nothing). If you can afford to waste CPU, one approach would be for make(1) to setrlimit(2) child processes and if the child dies, it retries that child by itself - but that will generate unnecessary retries. Another, more involved, approach would be for the scheduler to manage groups of processes - if a group of processes is causing memory pressure as a whole then the scheduler just stops scheduling some of them until the pressure reduces (effectively swap them out). (Yes, that's vague and lots of hand-waving that might not be realisable). --=20 Peter Jeremy --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCRjRAACgkQ/opHv/APuIf8bACeKtbpNmaXSp2R6mEFNY16AeyK LiAAoKRUiIC+YlaaUmdMXdz27947sC98 =KqHt -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 20:44:15 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1996653 for ; Wed, 31 Oct 2012 20:44:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8AFA88FC08 for ; Wed, 31 Oct 2012 20:44:14 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1328015pad.13 for ; Wed, 31 Oct 2012 13:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=j2cQMK2H1C0mh7c8KxYoYPkOFo9RTtCqWoOjWESlTwY=; b=XM0TdOnm103rPQeHXlxTV4jVC0jGWh88RSHOd90S0BRgh1lrGEu/KT/9BqwutOWm2P /qgVBGT+ttlhuFpZglAN9OTaTdRHCZFy3s9ccSX9uZYzLM94M+pysiWUyFMUIUxkCSxU r1qTeKzmmf70UcJ5L0uZEeI7o3TZKMGI0j1kpHmHfICk/Lm4VU4nqQlv/iug/fMORsTJ 8nbid9zeh8Zy/YSKoCN23MObgUfqFP9o/Q7x+no8balLVZtKLKbGefDdzb/+iLwtweDH jevplo85m29qto9B4tIebL8hNA5FGruGX/XFogyw6oN8/Z1W+g1E0fTOWZ96s/zaNenb VDAw== MIME-Version: 1.0 Received: by 10.68.251.197 with SMTP id zm5mr81481299pbc.30.1351716254143; Wed, 31 Oct 2012 13:44:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 31 Oct 2012 13:44:14 -0700 (PDT) In-Reply-To: <20121031204152.GK3309@server.rulingia.com> References: <509182DA.8070303@mu.org> <20121031204152.GK3309@server.rulingia.com> Date: Wed, 31 Oct 2012 13:44:14 -0700 X-Google-Sender-Auth: F8V6DSJSNWE0U9OsqX5MMlE7BuA Message-ID: Subject: Re: make -jN buildworld on < 512MB ram From: Adrian Chadd To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:44:16 -0000 On 31 October 2012 13:41, Peter Jeremy wrote: > Another, more involved, approach would be for the scheduler to manage > groups of processes - if a group of processes is causing memory > pressure as a whole then the scheduler just stops scheduling some of > them until the pressure reduces (effectively swap them out). (Yes, > that's vague and lots of hand-waving that might not be realisable). Well, does the compiler actually need that much memory? :) Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 21:21:52 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56FB6CAB for ; Wed, 31 Oct 2012 21:21:52 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 39C5F8FC17 for ; Wed, 31 Oct 2012 21:21:51 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 764461A3CBC; Wed, 31 Oct 2012 14:21:51 -0700 (PDT) Message-ID: <5091966F.6070706@mu.org> Date: Wed, 31 Oct 2012 14:21:51 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Peter Jeremy Subject: Re: make -jN buildworld on < 512MB ram References: <509182DA.8070303@mu.org> <20121031204152.GK3309@server.rulingia.com> In-Reply-To: <20121031204152.GK3309@server.rulingia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:21:52 -0000 On 10/31/12 1:41 PM, Peter Jeremy wrote: > On 2012-Oct-31 12:58:18 -0700, Alfred Perlstein wrote: >> It seems like the new compiler likes to get up to ~200+MB resident when >> building some basic things in our tree. > The killer I found was the ctfmerge(1) on the kernel - which exceeds > ~400MB on i386. Under low RAM, that fails _without_ reporting any > errors back to make(1), resulting in a corrupt new kernel (it booted > but had virtually no devices so it couldn't find root). Trolled by FreeBSD. :) > >> Doesn't our make(1) have some stuff to mitigate this? I would expect it >> to be a bit smarter about detecting the number of swaps/pages/faults of >> its children and taking into account the machine's total ram before >> forking off new processes. > The difficulty I see is that the make process can't tell anything > about the memory requirements of the pipeline it is about to spawn. > As a rule of thumb, C++ needs more memory than C but that depends > on what is being compiled - I have a machine-generated C program that > makes gcc bloat to ~12GB. Ah, but make(1) can delay spawning any new processes when it knows its children are paging. This is sort of like "well you can't predict when an elevator will plunge to its doom." ...but you can stop loading hapless people onto it when it starts creaking... (paging/swapping). > >> Any ideas? I mean a really simple algorithm could be devised that would >> be better than what we appear to have (which is nothing). > If you can afford to waste CPU, one approach would be for make(1) to > setrlimit(2) child processes and if the child dies, it retries that > child by itself - but that will generate unnecessary retries. This doesn't really help. > > Another, more involved, approach would be for the scheduler to manage > groups of processes - if a group of processes is causing memory > pressure as a whole then the scheduler just stops scheduling some of > them until the pressure reduces (effectively swap them out). (Yes, > that's vague and lots of hand-waving that might not be realisable). > I think that could be done, this is actually a very interesting idea. Another idea is for make(1) to start to kill -STOP a child when it detects a lot of child paging until other independent children complete running, which is basically what I do manually when my build explodes until it gets past some C++ bits. *ugh* -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 21:29:52 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F83E5A3; Wed, 31 Oct 2012 21:29:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF5A78FC0C; Wed, 31 Oct 2012 21:29:50 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2435893oag.13 for ; Wed, 31 Oct 2012 14:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gAK3CX9FIOWj6vDxQEy6gn/VExqCLy83J7kW0lU1j7Q=; b=cRg1ZlKa26k2NEe2R2q7kLD3M/Trtb8Y+A2IIu+uah0k5T1cQfIqvPRgfKJW8WL2Yb mY9Lw/vlJiNDWF64rTgIsstx2+breqtVRnMB8tMBVCp7ffNQhI7qKqVpBpNK84Y64zVE XLwrmxbd6P1ORLE7UKzjkMUUrW9fNLfWq08ViN9g5Ycgicg/6xBMX1zciHGwm5I6dmMy UuVFhbNwQ4LNTSC5KzRmt/zanT1QCsXZsyxV82BjzZl5J96NLape6+RwRS8uq61R7i+n wuIUj0h52e7+PbuEZequFM1J9S4Qy+rIzhdmUjpf8VcWMY8JGNSewu40EQARRTZECqzY 13Hg== MIME-Version: 1.0 Received: by 10.60.28.42 with SMTP id y10mr5195036oeg.24.1351718990114; Wed, 31 Oct 2012 14:29:50 -0700 (PDT) Received: by 10.76.143.33 with HTTP; Wed, 31 Oct 2012 14:29:50 -0700 (PDT) In-Reply-To: References: <509182DA.8070303@mu.org> <20121031204152.GK3309@server.rulingia.com> Date: Wed, 31 Oct 2012 14:29:50 -0700 Message-ID: Subject: Re: make -jN buildworld on < 512MB ram From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Alfred Perlstein , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:29:52 -0000 On Wed, Oct 31, 2012 at 1:44 PM, Adrian Chadd wrote: > On 31 October 2012 13:41, Peter Jeremy wrote: > >> Another, more involved, approach would be for the scheduler to manage >> groups of processes - if a group of processes is causing memory >> pressure as a whole then the scheduler just stops scheduling some of >> them until the pressure reduces (effectively swap them out). (Yes, >> that's vague and lots of hand-waving that might not be realisable). > > Well, does the compiler actually need that much memory? :) For calculating SSAs, directed graphs, and when dealing with larger optimization levels -- sadly, yes it can. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 22:14:51 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A372745E for ; Wed, 31 Oct 2012 22:14:51 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 32F618FC0A for ; Wed, 31 Oct 2012 22:14:50 +0000 (UTC) Received: from server.rulingia.com (c220-239-241-202.belrs5.nsw.optusnet.com.au [220.239.241.202]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q9VMEjiP038058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Nov 2012 09:14:46 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q9VMEdOA040808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2012 09:14:39 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q9VMEdCR040807; Thu, 1 Nov 2012 09:14:39 +1100 (EST) (envelope-from peter) Date: Thu, 1 Nov 2012 09:14:39 +1100 From: Peter Jeremy To: Alfred Perlstein Subject: Re: make -jN buildworld on < 512MB ram Message-ID: <20121031221439.GM3309@server.rulingia.com> References: <509182DA.8070303@mu.org> <20121031204152.GK3309@server.rulingia.com> <5091966F.6070706@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/" Content-Disposition: inline In-Reply-To: <5091966F.6070706@mu.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:14:51 -0000 --3XA6nns4nE4KvaS/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Oct-31 14:21:51 -0700, Alfred Perlstein wrote: >Ah, but make(1) can delay spawning any new processes when it knows its=20 >children are paging. That could work in some cases and may be worth implementing. Where it won't work is when make(1) initially hits a parallelisable block of "big" programs after a series of short, small tasks: System is OK so the first big program is spawned. ~100msec later, the next small task finishes. System in still OK (because the first big task is still growing and hasn't achieved peak bloat[*]) so it spawns another big task. Repeat a few times and you have a collection of big processes starting to thrash the system. >> Another, more involved, approach would be for the scheduler to manage >> groups of processes - if a group of processes is causing memory >> pressure as a whole then the scheduler just stops scheduling some of >> them until the pressure reduces (effectively swap them out). (Yes, >> that's vague and lots of hand-waving that might not be realisable). >> >I think that could be done, this is actually a very interesting idea. > >Another idea is for make(1) to start to kill -STOP a child when it=20 >detects a lot of child paging until other independent children complete=20 >running, which is basically what I do manually when my build explodes=20 >until it gets past some C++ bits. This is roughly a userland variant of the scheduler change above. The downside is that make(1) can no longer just wait(2) for a process to exit and then decide what to do next. Instead, it needs to poll the system's paging activity and take action on one of its children. Some of the special cases it needs ta handle are: 1) The offending process isn't a direct child but a more distant=20 descendent - this will be the typical case: make(1) starts gcc(1) which spawns cc1plus which bloats. 2) Multiple (potentially independent) make(1) processes all detect that the system is too busy and stop their children. Soon after, the system is free so they all SIGCONT their children. Repeat. (Note that any scheduler changes also need to cope with this). [*] Typical cc1/cc1plus behaviour is to steadily grow as the input is processed. At higher optimisation levels, parse trees are not freed at the end of a function to allow global inlining and optimisation. --=20 Peter Jeremy --3XA6nns4nE4KvaS/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCRos8ACgkQ/opHv/APuIf3kwCeMi5LYN1EUby33hKzzuN/htpI gkYAni/+wCXieiDSKoPIOgmhQEH/5vTp =oNfW -----END PGP SIGNATURE----- --3XA6nns4nE4KvaS/-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 22:39:22 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 933F7A39 for ; Wed, 31 Oct 2012 22:39:22 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 747B68FC0C for ; Wed, 31 Oct 2012 22:39:22 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id C68C41A3CC6; Wed, 31 Oct 2012 15:39:21 -0700 (PDT) Message-ID: <5091A899.9070603@mu.org> Date: Wed, 31 Oct 2012 15:39:21 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Peter Jeremy Subject: Re: make -jN buildworld on < 512MB ram References: <509182DA.8070303@mu.org> <20121031204152.GK3309@server.rulingia.com> <5091966F.6070706@mu.org> <20121031221439.GM3309@server.rulingia.com> In-Reply-To: <20121031221439.GM3309@server.rulingia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:39:22 -0000 On 10/31/12 3:14 PM, Peter Jeremy wrote: > On 2012-Oct-31 14:21:51 -0700, Alfred Perlstein wrote: >> Ah, but make(1) can delay spawning any new processes when it knows its >> children are paging. > That could work in some cases and may be worth implementing. Where it > won't work is when make(1) initially hits a parallelisable block of > "big" programs after a series of short, small tasks: System is OK so > the first big program is spawned. ~100msec later, the next small task > finishes. System in still OK (because the first big task is still > growing and hasn't achieved peak bloat[*]) so it spawns another big task. > Repeat a few times and you have a collection of big processes starting > to thrash the system. True, but the idea is to somewhat mitigate it, not solve it completely. So sure, you might thrash for a while, but I've seen buildworld thrash for HOURS not making any progress, so even if it thrashes for a bit that is a big win over endless thrashing. >>> Another, more involved, approach would be for the scheduler to manage >>> groups of processes - if a group of processes is causing memory >>> pressure as a whole then the scheduler just stops scheduling some of >>> them until the pressure reduces (effectively swap them out). (Yes, >>> that's vague and lots of hand-waving that might not be realisable). >>> >> I think that could be done, this is actually a very interesting idea. >> >> Another idea is for make(1) to start to kill -STOP a child when it >> detects a lot of child paging until other independent children complete >> running, which is basically what I do manually when my build explodes >> until it gets past some C++ bits. > This is roughly a userland variant of the scheduler change above. The > downside is that make(1) can no longer just wait(2) for a process to > exit and then decide what to do next. Instead, it needs to poll the > system's paging activity and take action on one of its children. Some > of the special cases it needs ta handle are: > 1) The offending process isn't a direct child but a more distant > descendent - this will be the typical case: make(1) starts gcc(1) > which spawns cc1plus which bloats. > 2) Multiple (potentially independent) make(1) processes all detect that > the system is too busy and stop their children. Soon after, the > system is free so they all SIGCONT their children. Repeat. (Note > that any scheduler changes also need to cope with this). > > [*] Typical cc1/cc1plus behaviour is to steadily grow as the input is > processed. At higher optimisation levels, parse trees are not > freed at the end of a function to allow global inlining and > optimisation. > Sure, these are obstacles, but I do not think they are insurmountable. 1 can be addressed by walking the process tree. 2 can be addressed by simply setting an environment flag that denotes the MASTER process, so that subchildren do not try to schedule as well. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 02:12:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D501DBE for ; Thu, 1 Nov 2012 02:12:30 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0308FC08; Thu, 1 Nov 2012 02:12:30 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA12CSVM098128; Thu, 1 Nov 2012 02:12:29 GMT (envelope-from davidxu@freebsd.org) Message-ID: <5091DA90.7050507@freebsd.org> Date: Thu, 01 Nov 2012 10:12:32 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Karl Pielorz Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 02:12:30 -0000 On 2012/10/31 22:44, Karl Pielorz wrote: > > > --On 31 October 2012 16:06 +0200 Konstantin Belousov > wrote: > >> Since you neglected to provide the verbatim output of procstat, nothing >> conclusive can be said. Obviously, you can make an investigation on your >> own. > > Sorry - when I ran it this morning the output was several hundred lines > - I didn't want to post all of that to the list 99% of the lines are > very similar. I can email it you off-list if having the whole lot will > help? > >>> Then there's a bunch of 'large' blocks e.g.. >>> >>> PID START END PRT RES PRES REF SHD FL TP >>> PATH 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 >>> ---- df 2010 0x802800000 0x803400000 rw- 1880 0 1 0 >> >> Most likely, these are malloc arenas. > > Ok, that's the heaviest usage. > >>> Then lots of 'little' blocks, >>> >>> 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D df >> >> And those are thread stacks. > > Ok, lots of those (lots of threads going on) - but they're all pretty > small. > Note that libc_r's thread stack is 64K, while libthr has 1M bytes per-thread. > My code only has a single call to malloc, which allocates around 20k per > thread. > > Obviously there's other libraries and stuff running with the code - so > would I be correct in guessing that they are more than likely for most > of these large blocks? > > -Karl > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 14:19:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6D70F6A; Thu, 1 Nov 2012 14:19:58 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id F40A18FC16; Thu, 1 Nov 2012 14:19:57 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA1EJvKC045903; Thu, 1 Nov 2012 08:19:57 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA1EJsK2007725; Thu, 1 Nov 2012 08:19:54 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Ian Lepore To: David Xu In-Reply-To: <5091DA90.7050507@freebsd.org> References: <20121030182727.48f5e649@X220.ovitrap.com> <20121030194307.57e5c5a3@X220.ovitrap.com> <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <5091DA90.7050507@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Nov 2012 08:19:54 -0600 Message-ID: <1351779594.1120.128.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Alfred Perlstein , Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:19:58 -0000 On Thu, 2012-11-01 at 10:12 +0800, David Xu wrote: > On 2012/10/31 22:44, Karl Pielorz wrote: > > > > > > --On 31 October 2012 16:06 +0200 Konstantin Belousov > > wrote: > > > >> Since you neglected to provide the verbatim output of procstat, nothing > >> conclusive can be said. Obviously, you can make an investigation on your > >> own. > > > > Sorry - when I ran it this morning the output was several hundred lines > > - I didn't want to post all of that to the list 99% of the lines are > > very similar. I can email it you off-list if having the whole lot will > > help? > > > >>> Then there's a bunch of 'large' blocks e.g.. > >>> > >>> PID START END PRT RES PRES REF SHD FL TP > >>> PATH 2010 0x801c00000 0x802800000 rw- 2869 0 4 0 > >>> ---- df 2010 0x802800000 0x803400000 rw- 1880 0 1 0 > >> > >> Most likely, these are malloc arenas. > > > > Ok, that's the heaviest usage. > > > >>> Then lots of 'little' blocks, > >>> > >>> 2010 0x7ffff0161000 0x7ffff0181000 rw- 16 0 1 0 ---D df > >> > >> And those are thread stacks. > > > > Ok, lots of those (lots of threads going on) - but they're all pretty > > small. > > > Note that libc_r's thread stack is 64K, while libthr has 1M bytes > per-thread. That would help explain the large increase in virtual size, but not the increase in resident size, right? In other words, there's nothing inherent in libthr that makes it use more stack, it just allocates more vmspace to allow greater potential growth? Hmmm, actually the chunks said to be thread stack above are neither 64K nor 1M, that's 128K. The malloc arenas are 12M, which seems like an unusual value. I haven't looked inside jemalloc at all, maybe that's normal. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 16:16:15 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 495DDD08 for ; Thu, 1 Nov 2012 16:16:15 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id D744C8FC16 for ; Thu, 1 Nov 2012 16:16:14 +0000 (UTC) X-AuditID: 12074423-b7fab6d0000008f9-a1-5092a0484d02 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 87.5D.02297.840A2905; Thu, 1 Nov 2012 12:16:08 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id qA1GG7E6008333; Thu, 1 Nov 2012 12:16:08 -0400 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qA1GG48c013025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2012 12:16:05 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id qA1GG3dC003711; Thu, 1 Nov 2012 12:16:03 -0400 (EDT) Date: Thu, 1 Nov 2012 12:16:03 -0400 (EDT) From: Benjamin Kaduk To: Peter Jeremy Subject: Re: make -jN buildworld on < 512MB ram In-Reply-To: <20121031204152.GK3309@server.rulingia.com> Message-ID: References: <509182DA.8070303@mu.org> <20121031204152.GK3309@server.rulingia.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixCmqrOuxYFKAwaxNYhYbFhRaPL37ndWB yWPGp/ksHotu3mULYIrisklJzcksSy3St0vgynhy5QBrQZNAxYKpnewNjA94uhg5OSQETCTe bZvECmGLSVy4t56ti5GLQ0hgH6PEv7P3mEASQgLrGSW+PsyHSBxnkrgx6x5zFyMHkFMv8avL EKSGRUBL4sTbJ8wgNpuAisTMNxvZQGwRAVWJQ6svgy1gFhCXWHivlwXEFhbQl9iwahYryBhO AQuJR5ucQcK8Ag4Sz2Z1M0OsDZSYtH4jWKuogI7E6v1TWCBqBCVOznzCAjHSUuLcn+tsExgF ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyMoRNldlHcw/jmo dIhRgINRiYfXoHRigBBrYllxZe4hRkkOJiVR3q9TJwUI8SXlp1RmJBZnxBeV5qQWH2KU4GBW EuF93A1UzpuSWFmVWpQPk5LmYFES572WctNfSCA9sSQ1OzW1ILUIJivDwaEkwVs+H2ioYFFq empFWmZOCUKaiYMTZDgP0HAdkBre4oLE3OLMdIj8KUZdjl998x4yCrHk5eelSonz1oMUCYAU ZZTmwc2BpZZXjOJAbwnzuoFU8QDTEtykV0BLmICWqFiAfFBckoiQkmpgnMHLNNFhg1Grf2bF lfBF9suZ2yYFq4TMmXbnVtZZjS9muxJ2pcdw3t28w3uj9ol4gzOPmzlnzeGcP2GCqsYEJvPX dr+4y2IWcgYJMpzas/7ex7cBgUHCr1d+XrAkuZRD7OC5C4GJv7oztkQxze3PrBfdkeX31vfZ 7KuOVRqH/2zLLpor++/sdyWW4oxEQy3mouJEAHAEWFEIAwAA Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:16:15 -0000 On Thu, 1 Nov 2012, Peter Jeremy wrote: > On 2012-Oct-31 12:58:18 -0700, Alfred Perlstein wrote: >> It seems like the new compiler likes to get up to ~200+MB resident when >> building some basic things in our tree. > > The killer I found was the ctfmerge(1) on the kernel - which exceeds > ~400MB on i386. Under low RAM, that fails _without_ reporting any > errors back to make(1), resulting in a corrupt new kernel (it booted > but had virtually no devices so it couldn't find root). > >> Doesn't our make(1) have some stuff to mitigate this? I would expect it >> to be a bit smarter about detecting the number of swaps/pages/faults of >> its children and taking into account the machine's total ram before >> forking off new processes. > > The difficulty I see is that the make process can't tell anything > about the memory requirements of the pipeline it is about to spawn. > As a rule of thumb, C++ needs more memory than C but that depends > on what is being compiled - I have a machine-generated C program that > makes gcc bloat to ~12GB. > >> Any ideas? I mean a really simple algorithm could be devised that would >> be better than what we appear to have (which is nothing). > > If you can afford to waste CPU, one approach would be for make(1) to > setrlimit(2) child processes and if the child dies, it retries that > child by itself - but that will generate unnecessary retries. > > Another, more involved, approach would be for the scheduler to manage > groups of processes - if a group of processes is causing memory > pressure as a whole then the scheduler just stops scheduling some of > them until the pressure reduces (effectively swap them out). (Yes, > that's vague and lots of hand-waving that might not be realisable). Starts to sound similar to parts of linux cgroups. Which, incidentally, a friend of mine was recently complaining about not being able to run systemd in the linuxolator due to the lack of certain syscalls pertaining to cgroups... -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 06:48:38 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27C7C6B2; Thu, 1 Nov 2012 06:48:38 +0000 (UTC) (envelope-from alfred@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 051BC8FC46; Thu, 1 Nov 2012 06:48:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id CCC43F1A; Wed, 31 Oct 2012 23:48:36 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by localhost (mail.ixsystems.com [127.0.0.1]) (maiad, port 10024) with ESMTP id 31112-06; Wed, 31 Oct 2012 23:48:36 -0700 (PDT) Received: from Alfreds-MacBook-Pro-5.local (unknown [10.8.0.18]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 6D54BF17; Wed, 31 Oct 2012 23:48:36 -0700 (PDT) Message-ID: <50921B44.20400@ixsystems.com> Date: Wed, 31 Oct 2012 23:48:36 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: hackers@freebsd.org, phk@freebsd.org, pjd@freebsd.org, mav@freebsd.org Subject: please review: patch to retain device name for dumpdev. X-Mailman-Approved-At: Fri, 02 Nov 2012 02:53:28 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 06:48:38 -0000 I've always wanted to be able to query the current dump device. This patch lets me do this. Poul-Henning, what do you think? Is there a nicer way? Perhaps a way to include the "/dev/$device" as the patch in its current form only stores "ada0p3". I think that is OK. Provide a device name in the sysctl tree for programs to query the state of crashdump target devices. This will be used to add a "-l" (ell) flag to dumpon(8) to list the currently configured dumpdev. /usr/9-stable % svn diff sys/dev/null sys/geom sys/kern sys/sys Index: sys/dev/null/null.c =================================================================== --- sys/dev/null/null.c (revision 242367) +++ sys/dev/null/null.c (working copy) @@ -91,7 +91,7 @@ case DIOCSKERNELDUMP: error = priv_check(td, PRIV_SETDUMPER); if (error == 0) - error = set_dumper(NULL); + error = set_dumper(NULL, NULL); break; case FIONBIO: break; Index: sys/geom/geom_dev.c =================================================================== --- sys/geom/geom_dev.c (revision 242367) +++ sys/geom/geom_dev.c (working copy) @@ -351,7 +351,7 @@ case DIOCSKERNELDUMP: u = *((u_int *)data); if (!u) { - set_dumper(NULL); + set_dumper(NULL, NULL); error = 0; break; } @@ -360,7 +360,7 @@ i = sizeof kd; error = g_io_getattr("GEOM::kerneldump", cp, &i, &kd); if (!error) { - error = set_dumper(&kd.di); + error = set_dumper(&kd.di, devtoname(dev)); if (!error) dev->si_flags |= SI_DUMPDEV; } @@ -518,7 +518,7 @@ /* Reset any dump-area set on this device */ if (dev->si_flags & SI_DUMPDEV) - set_dumper(NULL); + set_dumper(NULL, NULL); /* Destroy the struct cdev *so we get no more requests */ destroy_dev(dev); Index: sys/kern/kern_shutdown.c =================================================================== --- sys/kern/kern_shutdown.c (revision 242367) +++ sys/kern/kern_shutdown.c (working copy) @@ -711,18 +711,28 @@ printf("done\n"); } +static char dumpdevname[sizeof(((struct cdev*)NULL)->si_name)]; +SYSCTL_STRING(_kern_shutdown, OID_AUTO, dumpdevname, CTLFLAG_RD, + dumpdevname, 0, "Device for kernel dumps"); + /* Registration of dumpers */ int -set_dumper(struct dumperinfo *di) +set_dumper(struct dumperinfo *di, const char *devname) { if (di == NULL) { bzero(&dumper, sizeof dumper); + dumpdevname[0] = '\0'; return (0); } if (dumper.dumper != NULL) return (EBUSY); dumper = *di; + strlcpy(dumpdevname, devname, sizeof(dumpdevname)); + if (strlen(dumpdevname) != strlen(devname)) { + printf("set_dumper: device name truncated from '%s' -> '%s'\n", + devname, dumpdevname); + } return (0); } Index: sys/sys/conf.h =================================================================== --- sys/sys/conf.h (revision 242367) +++ sys/sys/conf.h (working copy) @@ -335,7 +335,7 @@ off_t mediasize; /* Space available in bytes. */ }; -int set_dumper(struct dumperinfo *); +int set_dumper(struct dumperinfo *, const char *_devname); int dump_write(struct dumperinfo *, void *, vm_offset_t, off_t, size_t); void dumpsys(struct dumperinfo *); int doadump(boolean_t); From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 08:06:48 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61E978F7; Thu, 1 Nov 2012 08:06:48 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 18B198FC12; Thu, 1 Nov 2012 08:06:47 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2FDE73B6B8; Thu, 1 Nov 2012 08:06:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qA186egq014236; Thu, 1 Nov 2012 08:06:40 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein Subject: Re: please review: patch to retain device name for dumpdev. In-reply-to: <50921B44.20400@ixsystems.com> From: "Poul-Henning Kamp" References: <50921B44.20400@ixsystems.com> Date: Thu, 01 Nov 2012 08:06:40 +0000 Message-ID: <14235.1351757200@critter.freebsd.dk> X-Mailman-Approved-At: Fri, 02 Nov 2012 02:53:54 +0000 Cc: mav@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 08:06:48 -0000 -------- In message <50921B44.20400@ixsystems.com>, Alfred Perlstein writes: >Poul-Henning, what do you think? Is there a nicer way? Perhaps a way >to include the "/dev/$device" I think there are private implemenations where dumpdev is a network thing, so too much magic string editing is probably not a good idea. Given that /dev is really just a view into GEOMs namespace, one could argue for "GEOM:ada0p3" that that may be going overboard in sematic correctness. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 13:11:58 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7FB727B; Thu, 1 Nov 2012 13:11:58 +0000 (UTC) (envelope-from alfred@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id A677F8FC16; Thu, 1 Nov 2012 13:11:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id 15DA811F5; Thu, 1 Nov 2012 06:11:58 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by localhost (mail.ixsystems.com [127.0.0.1]) (maiad, port 10024) with ESMTP id 48294-03; Thu, 1 Nov 2012 06:11:57 -0700 (PDT) Received: from [10.0.1.22] (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id B9FD911F3; Thu, 1 Nov 2012 06:11:57 -0700 (PDT) Message-ID: <5092751C.8060009@ixsystems.com> Date: Thu, 01 Nov 2012 06:11:56 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: please review: patch to retain device name for dumpdev. References: <50921B44.20400@ixsystems.com> <14235.1351757200@critter.freebsd.dk> In-Reply-To: <14235.1351757200@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Nov 2012 02:54:03 +0000 Cc: mav@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:11:58 -0000 On 11/1/12 1:06 AM, Poul-Henning Kamp wrote: > -------- > In message <50921B44.20400@ixsystems.com>, Alfred Perlstein writes: > >> Poul-Henning, what do you think? Is there a nicer way? Perhaps a way >> to include the "/dev/$device" > I think there are private implemenations where dumpdev is a network thing, > so too much magic string editing is probably not a good idea. > > Given that /dev is really just a view into GEOMs namespace, one could > argue for "GEOM:ada0p3" that that may be going overboard in sematic > correctness. Good point, thank you. I'll leave the patch as-is. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 18:15:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 475E2C8A for ; Thu, 1 Nov 2012 18:15:55 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C15B08FC08 for ; Thu, 1 Nov 2012 18:15:54 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so2590535lag.13 for ; Thu, 01 Nov 2012 11:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FarGUO5O0kkQJJPmOyLI2lUwS1esQh424/ZaBYv1Jj0=; b=iM26eZs0O/2xK8bsIQmyqsnFSzHMybk0ZX4tO54a6+4CQJffCUSb8K+avBCQwhBsni +Wn3t2/NS4Z5CBOeoLf7+kIhzEnoKNXZG3N/+X0QXm7ZDqJTOPB0lH6NNfar7cxOvwRs YRChxIn+DENzxqXl2uQYcQfjio2Ihi1o4dj51U5b9tkabW5dihB/8rg4enq3SKBQK6gM qn++BqRqm7kyOnGX/ae8Ok8dwvqbuJG7yX7NOB+XswY+dAZBhZyohCPdI+TGpL3T9o/u oSQ/Tf9OWOMINcTfArTM+/8Y9zEpjOI6UXGyJ2rmfw2dB3gH06ApKaQayzEAN7ceqG2w mFFQ== MIME-Version: 1.0 Received: by 10.112.102.230 with SMTP id fr6mr16243706lbb.112.1351793753513; Thu, 01 Nov 2012 11:15:53 -0700 (PDT) Received: by 10.112.134.106 with HTTP; Thu, 1 Nov 2012 11:15:53 -0700 (PDT) Date: Thu, 1 Nov 2012 19:15:53 +0100 Message-ID: Subject: ata-intel.c - Intel ICH(7) Controller working modes From: Michael Schuh To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 02 Nov 2012 11:21:01 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:15:55 -0000 Hi @all, after a nightmare of digging the Internet, testing this, testing that, etc i have found a (temporary possible) Solution for a bug, that i reported: http://www.freebsd.org/cgi/query-pr.cgi?pr=173251 This bug is related to ( ?all? ) Machines that are based on INTEL-ICH chipsets withouth the possibility to change its working mode from (compatibility) IDE to AHCI. FreeBSD could not detect any SATA drive. There is no BIOS option to change the working mode of the ICH controller. As you can read in my follow-ups i had to patch the kernel back to its old behavior prior to 8.3 RELEASE. Just that can't be the solution. May be i haven't seen anything that would to get pushed into the loader.conf, but i didn't found anything related that helped. +TUNABLE_INT("hw.ahci.force", &force_ahci); <<< The only thing i found in relation to this. just that didn't worked. May be a more experienced developer can take a look on it and find a way to set the controllers into the new AHCI working mode or fallback to IDE mode if failed on boot time? here some deeper knowledge about the settings. http://rants.atmurray.net/2009/06/sata-ahci-mode-on-systems-without-bios.html It seems that this is not persistent and gets everytime changed back from the Systems BIOS or the chip itself on initialization. in the article is also mentioned that not all chipsets supports ahci. while the author is referring to the same kind of machine, i think it should be possible to swithc the controller to ahci in my case. i could patch back the kernels ata-intel.c driver, just no idea what this means in deep and how i can put the stuff from the article above into it. to enforce a check before the driver gets loaded. i am not a kern developer. i am grateful for any hint or help. from my point of view it would be nice if we can get a working solution into the kernel, so people that use those machines didn't have to patch their kernels all the time. i found more ppl. with that problem. many thanks michael p.s. i am not member of that mailing list, so i will see only answers sent to myself (not only to the list) From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 14:03:06 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 753F7B25; Fri, 2 Nov 2012 14:03:06 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by mx1.freebsd.org (Postfix) with ESMTP id B02738FC14; Fri, 2 Nov 2012 14:03:05 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.80,699,1344229200"; d="scan'208";a="7810377" Message-ID: <5093D254.5010702@vangyzen.net> Date: Fri, 2 Nov 2012 09:01:56 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: please review: patch to retain device name for dumpdev. References: <50921B44.20400@ixsystems.com> In-Reply-To: <50921B44.20400@ixsystems.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:03:06 -0000 On 11/01/2012 01:48, Alfred Perlstein wrote: > /* Registration of dumpers */ > int > -set_dumper(struct dumperinfo *di) > +set_dumper(struct dumperinfo *di, const char *devname) > { > > if (di == NULL) { > bzero(&dumper, sizeof dumper); > + dumpdevname[0] = '\0'; > return (0); > } > if (dumper.dumper != NULL) > return (EBUSY); > dumper = *di; > + strlcpy(dumpdevname, devname, sizeof(dumpdevname)); > + if (strlen(dumpdevname) != strlen(devname)) { You can use the return value of strlcpy() to test for truncation, and save two strlen()s: if (strlcpy(...) >= sizeof(dst)) { /* truncated */ } > + printf("set_dumper: device name truncated from '%s' -> '%s'\n", > + devname, dumpdevname); > + } > return (0); > } From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 14:42:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C81E1C7; Fri, 2 Nov 2012 14:42:35 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail.palisadesystems.com (mail.palisadesystems.com [216.81.178.129]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4938FC08; Fri, 2 Nov 2012 14:42:35 +0000 (UTC) Received: from [192.168.221.153] ([192.168.221.153]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id qA2EUenC064918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Nov 2012 09:30:48 -0500 (CDT) (envelope-from guy.helmer@gmail.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com qA2EUenC064918 From: Guy Helmer Subject: Panic in bpf.c catchpacket() Message-Id: Date: Fri, 2 Nov 2012 09:30:40 -0500 To: freebsd-hackers@freebsd.org, "freebsd-net@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Fri, 02 Nov 2012 09:30:48 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: qA2EUenC064918 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.085, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, FREEMAIL_FROM 1.00, HTML_MESSAGE 0.00, RP_8BIT 1.98) X-Palisade-MailScanner-From: guy.helmer@gmail.com X-Spam-Status: No X-Mailman-Approved-At: Fri, 02 Nov 2012 17:59:47 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:42:35 -0000 Still working this problem I've previously mentioned, and my working = theory now is a race between catchpacket() and this code in bpfread(): /* * At this point, we know we have something in the hold slot. */ BPFD_UNLOCK(d); /* * Move data from hold buffer into user space. * We know the entire buffer is transferred since * we checked above that the read buffer is bpf_bufsize bytes. * * XXXRW: More synchronization needed here: what if a second = thread * issues a read on the same fd at the same time? Don't want = this * getting invalidated. */ error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); =20 BPFD_LOCK(d); d->bd_fbuf =3D d->bd_hbuf; d->bd_hbuf =3D NULL; d->bd_hlen =3D 0; bpf_buf_reclaimed(d); BPFD_UNLOCK(d); Assuming it's unwise to hold the descriptor lock over the uiomove() = call, it seems we at least need to check to make sure bd_hbuf is still = valid: @@ -809,10 +948,15 @@ bpfread(struct cdev *dev, struct uio *uio, int iof error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); =20 BPFD_LOCK(d); - d->bd_fbuf =3D d->bd_hbuf; - d->bd_hbuf =3D NULL; - d->bd_hlen =3D 0; - bpf_buf_reclaimed(d); + if (d->bd_hbuf =3D=3D NULL) { + printf("bpfread: lost race: bd_hbuf=3D%p bd_sbuf=3D%p = bd_fbuf=3D%p\n", + d->bd_hbuf, d->bd_sbuf, d->bd_fbuf); + } else { + d->bd_fbuf =3D d->bd_hbuf; + d->bd_hbuf =3D NULL; + d->bd_hlen =3D 0; + bpf_buf_reclaimed(d); + } BPFD_UNLOCK(d); =20 return (error); This still seems vulnerable to me -- a ROTATE_BUFFERS() or reset_d() = could be done between the BPFD_UNLOCK() and the bpf_uiomove(). Would a = new lock to protect the buffers be necessary, or a flag+condition = variable to indicate "hold buffer in use"? Guy= From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 20:23:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A7379F1; Fri, 2 Nov 2012 20:23:37 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4C18FC08; Fri, 2 Nov 2012 20:23:36 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id qA2KDIj2024804; Fri, 2 Nov 2012 20:13:18 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id qA2KDIn8024803; Fri, 2 Nov 2012 20:13:18 GMT (envelope-from wkoszek) Date: Fri, 2 Nov 2012 20:13:18 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121102201318.GI59689@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20121016101957.GB53800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Fri, 02 Nov 2012 20:13:18 +0000 (UTC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 20:23:37 -0000 On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. Hello, This is last call for action. As for now, we won't qualify. I suggest doc@ and ports@ and www@ and src@ teams to try to come up with some ideas and add them to Wiki. Most of the ideas which we have so far are more GSOC-alike. Unless we have at least 80 tasks of the "easy"/"medium" type, we'll have to postpone participating in Code-In for next year. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 17:48:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D6D8D4C; Sat, 3 Nov 2012 17:48:06 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0598FC15; Sat, 3 Nov 2012 17:47:58 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA3HlwST035914; Sat, 3 Nov 2012 11:47:58 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA3HltXb010080; Sat, 3 Nov 2012 11:47:55 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> <20121031190623.GL73505@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Nov 2012 11:47:54 -0600 Message-ID: <1351964874.1120.73.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Karl Pielorz , Alfred Perlstein , Dan Nelson , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 17:48:06 -0000 On Wed, 2012-10-31 at 13:38 -0700, Adrian Chadd wrote: > On 31 October 2012 12:06, Konstantin Belousov wrote: > > > Watchdogd was recently changed to mlock its memory. This is the cause > > of the RSS increase. > > > > If not wired, swapout might cause a delay of the next pat, leading to > > panic. > > Right, but look at the virtual size of the 6.4 process. It's not 10 > megabytes at all. Even if you wired all of that into memory, it > wouldn't be 10 megabytes. > > > > Adrian After gathering some more evidence, I agree that the huge increase I noticed in watchdogd is caused by a combo of jemalloc's behavior and the recent addition of mlockall(2) to watchdogd. Since this is only slightly tangentially related to the OP's questions as near as I can tell, I've entered a PR for it[1], and we can followup with a separate discusssion thread about that. While jemalloc can explain the growth in VSZ between 6.4 and 9.x, it doesn't look like mlockall() has anything to do with the original question of why the RSZ got so much bigger. In other words, part of the original question is still unanswered. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=173332 -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 18:11:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABA458B6; Sat, 3 Nov 2012 18:11:19 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E2E2B8FC08; Sat, 3 Nov 2012 18:11:18 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id b5so4157145lbd.13 for ; Sat, 03 Nov 2012 11:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UMd+0dh2KhvR9xEGc88FipKn09XTJrxFAYnBfJ1zEfE=; b=B9q/9HsNtpTeDYojD6Swk4fswrvb4B0DfQjoarOw+JKjOqZPBUKGl7pq9+rJl+j/lx gfk8vkmTHRleuqoBESrfaH87oDQNBLOnPYU0Y9SoSdsK1wlT3VZ07ucmhMHZgII2tMSB sRoJsf47Po7nyWZUeY8HP4ZI0wFQPDnQR59LKPeG58fK6OHCJ0t7CqR7kr9z+OqlEzFh gUPsKOtR3OQw0NZMkEL6Sw53NcvhwvZ9Pz9pj4zzc7wu0pmAp89FR8Gme63UsT91Xpry h6R+DWjQEVeS27FAUawHyJIZXT7LxiFQ2iKS8Hka8lPi5enIzdqOE1vXDQoNdS9sD6CE FBfA== MIME-Version: 1.0 Received: by 10.152.103.243 with SMTP id fz19mr4811745lab.27.1351966277775; Sat, 03 Nov 2012 11:11:17 -0700 (PDT) Received: by 10.114.61.103 with HTTP; Sat, 3 Nov 2012 11:11:17 -0700 (PDT) In-Reply-To: <20121031190623.GL73505@kib.kiev.ua> References: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> <20121031190623.GL73505@kib.kiev.ua> Date: Sat, 3 Nov 2012 13:11:17 -0500 Message-ID: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Alan Cox To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Ian Lepore , Adrian Chadd , freebsd-hackers@freebsd.org, Alfred Perlstein , Dan Nelson , Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:11:19 -0000 On Wed, Oct 31, 2012 at 2:06 PM, Konstantin Belousov wrote: > On Wed, Oct 31, 2012 at 11:52:06AM -0700, Adrian Chadd wrote: > > On 31 October 2012 11:20, Ian Lepore > wrote: > > > I think there are some things we should be investigating about the > > > growth of memory usage. I just noticed this: > > > > > > Freebsd 6.2 on an arm processor: > > > > > > 369 root 1 8 -88 1752K 748K nanslp 3:00 0.00% watchdogd > > > > > > Freebsd 10.0 on the same system: > > > > > > 367 root 1 -52 r0 10232K 10160K nanslp 10:04 0.00% watchdogd > > > > > > The 10.0 system is built with MALLOC_PRODUCTION (without that defined > > > the system won't even boot, it only has 64MB of ram). That's a crazy > > > amount of growth for a relatively simple daemon. > > > > Would you please, _please_ do some digging into this? > > > > It's quite possible there's something in the libraries that are > > allocating some memory upon first call invocation - yes, that's > > jemalloc, but it could also be other things like stdio. > > > > We really, really need to fix this userland bloat; it's terribly > > ridiculous at this point. There's no reason a watchdog daemon should > > take 10megabytes of RAM. > Watchdogd was recently changed to mlock its memory. This is the cause > of the RSS increase. > > Is it also statically linked? Alan From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 18:24:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7BB9FA3; Sat, 3 Nov 2012 18:24:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 644F28FC0C; Sat, 3 Nov 2012 18:24:16 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qA3IODlt018632; Sat, 3 Nov 2012 20:24:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qA3IODAU018631; Sat, 3 Nov 2012 20:24:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Nov 2012 20:24:12 +0200 From: Konstantin Belousov To: alc@freebsd.org Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121103182412.GB73505@kib.kiev.ua> References: <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> <20121031190623.GL73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+cTHE2B7cPyeMCYH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:24:16 -0000 --+cTHE2B7cPyeMCYH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 03, 2012 at 01:11:17PM -0500, Alan Cox wrote: > On Wed, Oct 31, 2012 at 2:06 PM, Konstantin Belousov wrote: >=20 > > On Wed, Oct 31, 2012 at 11:52:06AM -0700, Adrian Chadd wrote: > > > On 31 October 2012 11:20, Ian Lepore > > wrote: > > > > I think there are some things we should be investigating about the > > > > growth of memory usage. I just noticed this: > > > > > > > > Freebsd 6.2 on an arm processor: > > > > > > > > 369 root 1 8 -88 1752K 748K nanslp 3:00 0.00% watchdogd > > > > > > > > Freebsd 10.0 on the same system: > > > > > > > > 367 root 1 -52 r0 10232K 10160K nanslp 10:04 0.00% watchdogd > > > > > > > > The 10.0 system is built with MALLOC_PRODUCTION (without that defin= ed > > > > the system won't even boot, it only has 64MB of ram). That's a cra= zy > > > > amount of growth for a relatively simple daemon. > > > > > > Would you please, _please_ do some digging into this? > > > > > > It's quite possible there's something in the libraries that are > > > allocating some memory upon first call invocation - yes, that's > > > jemalloc, but it could also be other things like stdio. > > > > > > We really, really need to fix this userland bloat; it's terribly > > > ridiculous at this point. There's no reason a watchdog daemon should > > > take 10megabytes of RAM. > > Watchdogd was recently changed to mlock its memory. This is the cause > > of the RSS increase. > > > > > Is it also statically linked? No. I do not think that it is reasonable to statically link watchdogd. It might result in some memory saving, but I dislike the whole idea of static linkage on Tier 1 platforms. --+cTHE2B7cPyeMCYH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCVYUwACgkQC3+MBN1Mb4ihBgCgmllKOe59qY5KhOr3TWIhuwRo ZSsAnjxN5zeep8omSq4UiTrw8tV13Zea =oYuq -----END PGP SIGNATURE----- --+cTHE2B7cPyeMCYH-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 18:38:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F52D54D; Sat, 3 Nov 2012 18:38:49 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB4B8FC0A; Sat, 3 Nov 2012 18:38:48 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA3IcfhX037325; Sat, 3 Nov 2012 12:38:48 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA3Icees010121; Sat, 3 Nov 2012 12:38:40 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: watchdogd, jemalloc, and mlockall From: Ian Lepore To: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Nov 2012 12:38:39 -0600 Message-ID: <1351967919.1120.102.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:38:49 -0000 In an attempt to un-hijack the thread about memory usage increase between 6.4 and 9.x, I'm starting a new thread here related to my recent discovery that watchdogd uses a lot more memory since it began using mlockall(2). I tried statically linking watchdogd and it made a small difference in RSS, presumably because it doesn't wire down all of libc and libm. VSZ RSS 10236 10164 Dynamic 8624 8636 Static Those numbers are from ps -u on an arm platform. I just updated the PR (bin/173332) with some procstat -v output comparing with/without mlockall(). It appears that the bulk of the new RSS bloat comes from jemalloc allocating vmspace in 8MB chunks. With mlockall(MCL_FUTURE) in effect that leads to wiring 8MB to satisfy what probably amounts to a few hundred bytes of malloc'd memory. It would probably also be a good idea to remove the floating point from watchdogd to avoid wiring all of libm. The floating point is used just to turn the timeout-in-seconds into a power-of-two-nanoseconds value. There's probably a reasonably efficient way to do that without calling log(), considering that it only happens once at program startup. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 18:41:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81827694; Sat, 3 Nov 2012 18:41:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id DBA558FC08; Sat, 3 Nov 2012 18:41:51 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qA3Ifh4X020600; Sat, 3 Nov 2012 20:41:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qA3IfhMX020599; Sat, 3 Nov 2012 20:41:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Nov 2012 20:41:43 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: watchdogd, jemalloc, and mlockall Message-ID: <20121103184143.GC73505@kib.kiev.ua> References: <1351967919.1120.102.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I0oWFe1KborvVxk0" Content-Disposition: inline In-Reply-To: <1351967919.1120.102.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:41:52 -0000 --I0oWFe1KborvVxk0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 03, 2012 at 12:38:39PM -0600, Ian Lepore wrote: > In an attempt to un-hijack the thread about memory usage increase > between 6.4 and 9.x, I'm starting a new thread here related to my recent > discovery that watchdogd uses a lot more memory since it began using > mlockall(2). >=20 > I tried statically linking watchdogd and it made a small difference in > RSS, presumably because it doesn't wire down all of libc and libm. >=20 > VSZ RSS > 10236 10164 Dynamic > 8624 8636 Static >=20 > Those numbers are from ps -u on an arm platform. I just updated the PR > (bin/173332) with some procstat -v output comparing with/without > mlockall(). >=20 > It appears that the bulk of the new RSS bloat comes from jemalloc > allocating vmspace in 8MB chunks. With mlockall(MCL_FUTURE) in effect > that leads to wiring 8MB to satisfy what probably amounts to a few > hundred bytes of malloc'd memory. >=20 > It would probably also be a good idea to remove the floating point from > watchdogd to avoid wiring all of libm. The floating point is used just > to turn the timeout-in-seconds into a power-of-two-nanoseconds value. > There's probably a reasonably efficient way to do that without calling > log(), considering that it only happens once at program startup. No, I propose to add a switch to turn on/off the mlockall() call. I have no opinion on the default value of the suggested switch. --I0oWFe1KborvVxk0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCVZWcACgkQC3+MBN1Mb4hHhACguk/G8KdOYC2wQMMu6BH1WI8c BlkAnRwhcgc8SnQ62sV90VvzzrvX+cLf =s6o/ -----END PGP SIGNATURE----- --I0oWFe1KborvVxk0-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 18:50:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AB28BB9; Sat, 3 Nov 2012 18:50:58 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 30B4D8FC12; Sat, 3 Nov 2012 18:50:58 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA3Iovk6037697; Sat, 3 Nov 2012 12:50:57 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA3IoZj4010150; Sat, 3 Nov 2012 12:50:35 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: watchdogd, jemalloc, and mlockall From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20121103184143.GC73505@kib.kiev.ua> References: <1351967919.1120.102.camel@revolution.hippie.lan> <20121103184143.GC73505@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Nov 2012 12:50:35 -0600 Message-ID: <1351968635.1120.110.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:50:58 -0000 On Sat, 2012-11-03 at 20:41 +0200, Konstantin Belousov wrote: > On Sat, Nov 03, 2012 at 12:38:39PM -0600, Ian Lepore wrote: > > In an attempt to un-hijack the thread about memory usage increase > > between 6.4 and 9.x, I'm starting a new thread here related to my recent > > discovery that watchdogd uses a lot more memory since it began using > > mlockall(2). > > > > I tried statically linking watchdogd and it made a small difference in > > RSS, presumably because it doesn't wire down all of libc and libm. > > > > VSZ RSS > > 10236 10164 Dynamic > > 8624 8636 Static > > > > Those numbers are from ps -u on an arm platform. I just updated the PR > > (bin/173332) with some procstat -v output comparing with/without > > mlockall(). > > > > It appears that the bulk of the new RSS bloat comes from jemalloc > > allocating vmspace in 8MB chunks. With mlockall(MCL_FUTURE) in effect > > that leads to wiring 8MB to satisfy what probably amounts to a few > > hundred bytes of malloc'd memory. > > > > It would probably also be a good idea to remove the floating point from > > watchdogd to avoid wiring all of libm. The floating point is used just > > to turn the timeout-in-seconds into a power-of-two-nanoseconds value. > > There's probably a reasonably efficient way to do that without calling > > log(), considering that it only happens once at program startup. > > No, I propose to add a switch to turn on/off the mlockall() call. > I have no opinion on the default value of the suggested switch. In a patch I submitted along with the PR, I added code to query the vm.swap_enabled sysctl and only call mlockall() when swapping is enabled. Nobody yet has said anything about what seems to me to be the real problem here: jemalloc grabs 8MB at a time even if you only need to malloc a few bytes, and there appears to be no way to control that behavior. Or maybe there's a knob in there that didn't jump out at me on a quick glance through the header files. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 19:59:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73DA4F11 for ; Sat, 3 Nov 2012 19:59:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 5487F8FC08 for ; Sat, 3 Nov 2012 19:59:16 +0000 (UTC) Received: from Xins-MacBook-Pro.local (nat-dip5.cfw-a-gci.corp.yahoo.com [209.131.62.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 3BEA121158; Sat, 3 Nov 2012 12:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1351972756; bh=fP4UVmRIeOrbxxHjCRK+Wjvzczm8srMKl/BVtn+Enag=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=eEt3apahr4V95Z5j82mTIjX4PEVCzKEDO/astf3XrYxzgETXh+AGB3e+DfgEF9CrV RjDAFz08QdBT2saV98orTBB0skSy5WiknbqaL408tWqFzTQwTT7o7vrpFngZVW3cR4 2iTyspnOfc7yOk/H6BdX7jGiVC8rLlD/YWMWLVhY= Message-ID: <50957793.8060709@delphij.net> Date: Sat, 03 Nov 2012 12:59:15 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: watchdogd, jemalloc, and mlockall References: <1351967919.1120.102.camel@revolution.hippie.lan> In-Reply-To: <1351967919.1120.102.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 19:59:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/3/12 11:38 AM, Ian Lepore wrote: > In an attempt to un-hijack the thread about memory usage increase > between 6.4 and 9.x, I'm starting a new thread here related to my > recent discovery that watchdogd uses a lot more memory since it > began using mlockall(2). > > I tried statically linking watchdogd and it made a small difference > in RSS, presumably because it doesn't wire down all of libc and > libm. Speaking for this, the last time I brought this up, someone (can't remember, I think it was phk@) argued that the shared library would use only one copy of memory, while statically linked ones would be duplicated and thus use more memory. I haven't yet tried to prove or challenge that, though. Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQlXeTAAoJEG80Jeu8UPuz7AUIAJOn67ETS7uHuIaPNByr9R6l S6l8uhwqTOsF+4jmuuDmjI25uiCAN4a3OU8i4n/ZGuarlip2Rr4BFWf+FUkkzdyk qButTuWC/agpuKofJ/7UubTXIEhpViWY/J2mqQTwgk+zeQ0bl2yjaqaR4hH3/ivi DQ3FWGzBhWD0Ohx/B0f33i9wvc5mCTTR5oxM78xvrQIPejG3lQHcwgmsd5XLgAuW 54UEEnklxAYLDf9eCsDo9nSsXQBKidmZop3ELtg08gUxtu5Ncf1+QraLxjdFzdr7 RrmQgcR4QrVtQeezWCRx2Y8VzGl0rtOunmQguNgkwRLo3KQlIU4IhpnaNrNez74= =HAd6 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 20:12:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72BD01EB for ; Sat, 3 Nov 2012 20:12:41 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8DC8FC08 for ; Sat, 3 Nov 2012 20:12:34 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA3KCXSO040121 for ; Sat, 3 Nov 2012 14:12:33 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA3KCBE0010197; Sat, 3 Nov 2012 14:12:11 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: watchdogd, jemalloc, and mlockall From: Ian Lepore To: d@delphij.net In-Reply-To: <50957793.8060709@delphij.net> References: <1351967919.1120.102.camel@revolution.hippie.lan> <50957793.8060709@delphij.net> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Nov 2012 14:12:11 -0600 Message-ID: <1351973531.1120.118.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:12:41 -0000 On Sat, 2012-11-03 at 12:59 -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 11/3/12 11:38 AM, Ian Lepore wrote: > > In an attempt to un-hijack the thread about memory usage increase > > between 6.4 and 9.x, I'm starting a new thread here related to my > > recent discovery that watchdogd uses a lot more memory since it > > began using mlockall(2). > > > > I tried statically linking watchdogd and it made a small difference > > in RSS, presumably because it doesn't wire down all of libc and > > libm. > > Speaking for this, the last time I brought this up, someone (can't > remember, I think it was phk@) argued that the shared library would > use only one copy of memory, while statically linked ones would be > duplicated and thus use more memory. I haven't yet tried to prove or > challenge that, though. That sounds right to me... if 3 or 4 daemons were to eventually be statically linked because of mlockall(), then each of them would have its own private copy of strlen(), and malloc(), and so on; we'd be back to the bad old days before shared libs came along. Each program would contain its own copy of only the routines from the library that it uses, not the entire library in each program. On the other hand, if even one daemon linked with shared libc uses mlockall(), then all of libc gets wired. As I understand it, only one physical copy of libc would exist in memory, still shared by almost all running apps. The entire contents of the library would continuously occupy physical memory, even the parts that no apps are using. It's hard to know how to weigh the various tradeoffs. I suspect there's no one correct answer. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 21:12:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63E39BD7 for ; Sat, 3 Nov 2012 21:12:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 296228FC12 for ; Sat, 3 Nov 2012 21:12:25 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3323759pad.13 for ; Sat, 03 Nov 2012 14:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BwXmONEiLkOQt4qq48F57TwMzOvJoIBaRPzxgCbBjvA=; b=M7G2UaQomJKu3Kjic6YLsJ3AOIVEImp81TrzczUStLtdpCFhEvkC5N+hMI3CxeQCoT VyWSp0k1VgtOq4F2GZwnvQ54aMa7O+J0n5QRkiVqKX7SMU9DSyOPVu9Qz4kr0kZms/d0 dhAwfdOI5v8EP+1iEW4wsMYXzg8J9S5BrCMq/4FWrCu58/TszBDzZzxyEB7NbdEv1HGr ZR24TRTGVE0blX0d51Pvc6CJjZZz5jS6wwabSyKnT1dEdhDm92KFIzrcbc7TwsQWP9uo d8sulhh+cH4C7HjyngQKKlWi4fNE2aRfZSi1b0/tGk3oTaowxB1qevAdEUhX5xn2Thnb 9pmA== MIME-Version: 1.0 Received: by 10.66.79.168 with SMTP id k8mr16625800pax.12.1351977145305; Sat, 03 Nov 2012 14:12:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Sat, 3 Nov 2012 14:12:25 -0700 (PDT) In-Reply-To: <1351964874.1120.73.camel@revolution.hippie.lan> References: <615577FED019BCA31EC4211B@Octca64MkIV.tdx.co.uk> <509012D3.5060705@mu.org> <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> <20121031190623.GL73505@kib.kiev.ua> <1351964874.1120.73.camel@revolution.hippie.lan> Date: Sat, 3 Nov 2012 14:12:25 -0700 X-Google-Sender-Auth: AUbFPDVQCXPWZpiMISg0MaOlz5k Message-ID: Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Karl Pielorz , Alfred Perlstein , Dan Nelson , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 21:12:26 -0000 Hm, can you disable mlockall just to see what effect it has? Adrian