From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 16 06:13:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F4029286 for ; Sun, 16 Feb 2014 06:13:11 +0000 (UTC) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1991122B for ; Sun, 16 Feb 2014 06:13:08 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id s1G6D2Wl025338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 Feb 2014 22:13:02 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id s1G6D209025337; Sat, 15 Feb 2014 22:13:02 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA14886; Sat, 15 Feb 14 21:15:35 PST Date: Sat, 15 Feb 2014 21:16:17 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: jordan.hubbard@gmail.com Subject: Re: Thoughts on Multi-Symlink Concept Message-Id: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> References: In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 06:13:12 -0000 Jordan Hubbard wrote: > Even variant symlinks (/bin -> /${ARCH}/bin), which can expand > differently depending on the user context, have clearly > understandable semantics - you know that the symlink is going > to expand to exactly one file no matter what ARCH is set to. s/file/pathname/ Depending on what ARCH is set to, the expanision may or may not point to any actual file (or directory, or ...) From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 16 11:11:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 041224D4; Sun, 16 Feb 2014 11:11:55 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B710C148F; Sun, 16 Feb 2014 11:11:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 6323E3F4AD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1392549113; bh=1YEok5W3WRRe4z5jSbz55ecJDDiFetyEzUKLCgD+P4M=; h=Date:From:To:Cc:Subject; b=eRAL6XLE4J4EyND+WC4CFpuVhf/mcGYSvE0C/ZUMlzA7MqCdQ1InGBJl581JLeSHY r+fwhGYBaoyavMIV5Z093m52zImQ6WhEtZt4NWevCjkX8gPp93XDtFwqwlQfBfmY2S tfNm4Pluhq2fbGeRIV0hE+3WcksVqWG2nPCkXbZ4= Date: Sun, 16 Feb 2014 12:11:53 +0100 From: Ilya Bakulin To: Adrian Chadd , Alexander Motin , Warner Losh Subject: MMC/SDIO stack under CAM Message-ID: <20140216111153.GA74858@olymp.kibab.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 11:11:55 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi list, so I still want to move SDIO stack integration forward. As was already discussed, the best thing to do would be to have MMC stack under CAM. I have tried to understand how the CAM works for the existing drivers. Below is the structure for USB sticks: +-----------------------+ |Kernel (disk interface)| +-----------------------+ | BIO | +-------------------+ |da (storage driver)| +-------------------+ | CCB | +------------------------+ |CAM Layer sys/cam/scsi/*| +------------------------+ | CCB | +------------------+ |umass (HBA == SIM)| +------------------+ | usbd_* | +--------------------------+ |USB stack (and controller)| +--------------------------+ So da(4) doesn't know anything about USB. At this point I thought, that in this case da(4) will happily communicate with MMC/SD cards, if we provide a SIM for MMC! So the structure for MMC would be like this: +-----------------------+ |Kernel (disk interface)| +-----------------------+ | BIO | +-------------------+ |da (storage driver)| +-------------------+ | CCB | +------------------------+ |CAM Layer (sys/cam/mmc/*| +------------------------+ | CCB | +-------------------+ |mmc_cam (HBA == SIM| +-------------------+ | SD/MMC protocol (struct mmc_request) | +-------------------------------------------+ | MMC ctrlr driver (sdhci_ti, ..., mmcnull) | +-------------------------------------------+ | | +------------------+ | MMC/SD/SDIO Card | +------------------+ (the mmcnull driver is the pseudo-driver that I'm writing to make it possible to develop and test the whole thing on the VM). So MMC SIM and MMC controller driver would exchange mmc_requests, as it was before, with the exception that command completion will be reported differently (to utilize async callbacks system of CAM). For SDIO card, the situation will be different. Essentially, we should allow a device driver to send arbitrary messages to the card. So the device driver will attach directly to the scbus. Please let me know your thoughts about it. I really want SDIO make its way into the kernel, because there is an increasing number of ARM boards on the market that have integrated SDIO WLAN on them and we cannot support them fully. -- Ilya --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlMAnPcACgkQo9vlj1oadwhvqQCdHvVy3fWYl6m49MBpKpDfk2XG i/UAn1LsZym1H2QokRa3V9KowxHqgqrK =rC+Z -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 16 18:05:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 114B1B03 for ; Sun, 16 Feb 2014 18:05:45 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C72A211D8 for ; Sun, 16 Feb 2014 18:05:44 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id i4so16826583oah.11 for ; Sun, 16 Feb 2014 10:05:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QOZ2jb5M5CNdjVCDwj/oN5YST4Oq1B2qpZOi3TDSFHE=; b=SdFqTsUn79mk0yk8sOf5C1znUOFFUtNnV+51IxPs1Ve2Y5a90Jj3DbFBNyE6DxHchC 0h6/+xTllI+dx2wJVFYo6ucg5lpYq9C7Xj7Num6n/Lfxj3QKMIQL+cY0BYUIn009O/bH j4ihmFF9Qhw12aWaoQ5iVVam/ImOWswOVF73mpjoxXF5mMpp2tBpQyNss8Nt8RqRMZh+ Ov4zNxCP3ygUPzAc+XqsdUeREt9RcBe6ijS12xPk9bTqdQNPEum7IgWW0NQuhJbrpW1f iSL1QU4RCz3PknxLMWBg3BvSLAInDcYudjfQB8B1+s06OkvB+US6xc8CkoGDB1FgcFdR pIiA== X-Gm-Message-State: ALoCoQmFtyQsA2sTFV+aSxdYuGP51DbfLvYAvaWomth2DYebLPS7s6nKfVR5wLjzv+ilhjZdENHA X-Received: by 10.182.241.8 with SMTP id we8mr5116obc.62.1392573938012; Sun, 16 Feb 2014 10:05:38 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o6sm87669176oel.4.2014.02.16.10.05.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 10:05:36 -0800 (PST) Sender: Warner Losh Subject: Re: MMC/SDIO stack under CAM Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140216111153.GA74858@olymp.kibab.com> Date: Sun, 16 Feb 2014 11:05:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> References: <20140216111153.GA74858@olymp.kibab.com> To: Ilya Bakulin X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , freebsd-hackers@freebsd.org, Alexander Motin , freebsd-arm@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 18:05:45 -0000 On Feb 16, 2014, at 4:11 AM, Ilya Bakulin wrote: > Hi list, > so I still want to move SDIO stack integration forward. > As was already discussed, the best thing to do would be to > have MMC stack under CAM. > I have tried to understand how the CAM works for the existing drivers. >=20 > Below is the structure for USB sticks: >=20 > +-----------------------+ > |Kernel (disk interface)| > +-----------------------+ > | > BIO > | > +-------------------+ > |da (storage driver)| > +-------------------+ > | > CCB > | > +------------------------+ > |CAM Layer sys/cam/scsi/*| > +------------------------+ > | > CCB > | > +------------------+ > |umass (HBA =3D=3D SIM)| > +------------------+ > | > usbd_* > | > +--------------------------+ > |USB stack (and controller)| > +--------------------------+ >=20 > So da(4) doesn't know anything about USB. > At this point I thought, that in this case da(4) > will happily communicate with MMC/SD cards, if we provide > a SIM for MMC! So the structure for MMC would be like this: >=20 > +-----------------------+ > |Kernel (disk interface)| > +-----------------------+ > | > BIO > | > +-------------------+ > |da (storage driver)| > +-------------------+ > | > CCB > | > +------------------------+ > |CAM Layer (sys/cam/mmc/*| > +------------------------+ > | > CCB > | > +-------------------+ > |mmc_cam (HBA =3D=3D SIM| > +-------------------+ > | > SD/MMC protocol (struct mmc_request) > | > +-------------------------------------------+ > | MMC ctrlr driver (sdhci_ti, ..., mmcnull) | > +-------------------------------------------+ > | > | > +------------------+ > | MMC/SD/SDIO Card | > +------------------+ >=20 > (the mmcnull driver is the pseudo-driver that I'm writing > to make it possible to develop and test the whole thing > on the VM). that's cool! I'd thought of writing a mmcsim that I could use to develop = the stack on x86, but time pressures of my job precluded that (though in = hind sight, it would have saved a lot of time). > So MMC SIM and MMC controller driver would exchange mmc_requests, > as it was before, with the exception that command completion will be > reported differently (to utilize async callbacks system of CAM). >=20 > For SDIO card, the situation will be different. Essentially, > we should allow a device driver to send arbitrary messages to the = card. > So the device driver will attach directly to the scbus. >=20 > Please let me know your thoughts about it. > I really want SDIO make its way into the kernel, because there > is an increasing number of ARM boards on the market that have = integrated > SDIO WLAN on them and we cannot support them fully. Generally, I like this idea... I'd be very interested in some of the = specifics to make the direct attachment work with SDIO. That's the one = area I either don't think I understand your proposal well enough, or I = do and I'm concerned about it. :) So maybe write a bit more about the = details of the SDIO cards and how they's interact with CAM in this = scenario... The notion of moving MMC/SD into the CAM stack has been around since I = started working on MMC. At the time, CAM was too SCSI centric to do it, = but Alexander Motin's work has generally improved that situation, so it = may be possible now to do it and shake out the few dark corners of CAM = where this isn't the case. I also think it should help performance a lot = since we're currently single threaded to the card (but that's also the = nature of the bus), which introduces some round-trip latencies between = too many threads that CAM may help us avoid. Warner= From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 16 21:58:48 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75595372 for ; Sun, 16 Feb 2014 21:58:48 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 07DB312DF for ; Sun, 16 Feb 2014 21:58:47 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b15so6752910eek.29 for ; Sun, 16 Feb 2014 13:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yv1L8RknaCNlMrpk9R03bd+i0Yuk5+2eqA0v3kP1p7w=; b=0/N7SSOMCm+atZUGNTeXBpent8+7ce7KhLPiSYvVLL6enAMme/7E2LPpyRG5Muhkw5 P/bjmRSTiq/UHvZNty4D0gym8tO+KrxcXUnb9WD94qAbNZ+6VtGkyc15XrEoTLWlqeTo QMKneiKMlK5srhbhPZLZFWDZ/xVZWNrGXTmOVRup0xAabTznh8td1X0FzJDIv7YQuDS5 SHGlv398YdAQwIQATJZtEdn47rQ7vYH6IzLSjLwFDNr7EgSn5H1xEu5BnrPuEWJ1JMJi EvstoHyhAyJW1bb4GW0CG/KhAtf8EO2TiMZt4hiHVzp4/wbDN3RnagY5uk0ehcFPyMkN qGMg== X-Received: by 10.14.29.6 with SMTP id h6mr1606171eea.84.1392587926324; Sun, 16 Feb 2014 13:58:46 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id m9sm49424768eeh.3.2014.02.16.13.58.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Feb 2014 13:58:45 -0800 (PST) Sender: Mikolaj Golub Date: Sun, 16 Feb 2014 23:58:43 +0200 From: Mikolaj Golub To: Photo stuff Subject: Re: The sonewconn listen queue overflow issue Message-ID: <20140216215842.GB14237@gmail.com> References: <52EFEEF7.5010704@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52EFEEF7.5010704@xs4all.nl> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:58:48 -0000 On Mon, Feb 03, 2014 at 08:33:11PM +0100, Photo stuff wrote: > sonewconn: pcb 0xyyyyyyyyyyyyyyyy: Listen queue overflow: 8 already in > queue awaiting acceptance > > I searched a bit on the web and came across recommendations to try > netstat -nAa to find out which program this came from. > > Well, running netstat -nAa |grep pcb 0xyyyyyyyyyyyyyyyy in a loop didn't > work, it didn't give any output even though the messages kept coming in > the log during that time. Unfortunately, netstat(1) shows tcpcb address for TCP sockets, while in debug messages like above the socket's pcb is printed. It looks like the simplest way to assiciate a socket with the reported pcb address is to hack netstat(1) to output pcb instead of tcpcb: Index: usr.bin/netstat/inet.c =================================================================== --- usr.bin/netstat/inet.c (revision 261639) +++ usr.bin/netstat/inet.c (working copy) @@ -448,7 +448,7 @@ protopr(u_long off, const char *name, int af1, int if (Lflag && so->so_qlimit == 0) continue; if (Aflag) { - if (istcp) + if (0 && istcp) printf("%*lx ", 2 * (int)sizeof(void *), (u_long)inp->inp_ppcb); else printf("%*lx ", 2 * (int)sizeof(void *), (u_long)so->so_pcb); -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 01:12:42 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4B214C8; Mon, 17 Feb 2014 01:12:42 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FE7410B6; Mon, 17 Feb 2014 01:12:41 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s1H1CZlR064210; Sun, 16 Feb 2014 18:12:35 -0700 (MST) (envelope-from torek@torek.net) Message-Id: <201402170112.s1H1CZlR064210@elf.torek.net> From: Chris Torek To: Mikolaj Golub Subject: Re: The sonewconn listen queue overflow issue In-reply-to: Your message of "Sun, 16 Feb 2014 23:58:43 +0200." <20140216215842.GB14237@gmail.com> Date: Sun, 16 Feb 2014 18:12:35 -0700 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sun, 16 Feb 2014 18:12:35 -0700 (MST) Cc: hackers@freebsd.org, Photo stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 01:12:42 -0000 >Unfortunately, netstat(1) shows tcpcb address for TCP sockets, >while in debug messages like above the socket's pcb is printed. This happens because, in the place where the listen queue overflow occurs, we do not have access to that which would allow identifying the specific overflowing queue. Specifically, we only know the socket, and a PCB for it (so_pcb), and that happens to be an inpcb rather than a tcpcb, in the case of a TCP socket. (I'm not sure why the socket pcb is the inpcb in the first place. Seems like the whole system could have been designed to work from top down to bottom: so_pcb is the tcp or udp block, and from there we get the inpcb, etc. [This would match so_proto being the TCP or UDP protocol, etc.] But it wasn't, and reversing that is too painful now.) >It looks like the simplest way to assiciate a socket with the >reported pcb address is to hack netstat(1) to output pcb instead >of tcpcb: [snip patch] That's kind of going backwards though: dumbing down netstat just to handle some deliberate ignorance in the kernel. :-) I think a better fix might be to have a "report listen-queue overflow" function in the protocol (so_proto or its pr_usrreqs -- season to taste). For tcp sockets this could log the local address; other protocols would log something else as appropriate; and For backwards compatibility, if there is no reporting function, the existing code can remain as-is. Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 04:47:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF19DC15 for ; Mon, 17 Feb 2014 04:47:12 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67683135D for ; Mon, 17 Feb 2014 04:47:12 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id uq10so4477688igb.2 for ; Sun, 16 Feb 2014 20:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+HcHIfToM1PMpenJyCMjaqoZdgvXW+3Bv2IFyS4cP8s=; b=U3cX1yUnRQNA/dFlu13CV+boLTjxtEDcvboy5QCvNiBaO+C6I98YpzsK3bHsuIsQU5 s7AwjuQX/04HadWmJFTkfqLmbch/2qbH4lBu1Kzh6vXEejEy6Y+Uk8eKzemPPUPYexnT irjCZb/q+gtmr9OLQ9b5QCYyafPe/StRr4WEA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+HcHIfToM1PMpenJyCMjaqoZdgvXW+3Bv2IFyS4cP8s=; b=Bti1kGu9pQ++QWD48/HynpJXG+RJmppUWLmlZRh/Vf7oYEvGHSZHoqRaXzZEDTow4J v88fVHJmPD5wGmUx5CiszqZhQGQ2kXZvb1I5/b0mneZRETinr6kDz9PMD3115ZbmSFjz Xwd+3/Wn3QVwO6IU/NYuYt/GsR6arPbocSMPS52/OBrDn2QWuLT5fH4BcZ3rJoUmn4xr HMe+KDLpr8WB7NpOFYRTxQT4iKkzqPnipiefBdmmR+ouAAa68lU9hNBbyJbUQsFX0SjK 1+iocdtPobYmxBnfwz4dS7S88Fd0zVkH31PJDctOCOP7g5+wdtVfnl7AOuVWJ/2c/4Sd 5ysg== X-Gm-Message-State: ALoCoQmSb3be2JkGsEzsX+aUOJJyycE24kfBzVPj91wWm90hhGCYqRPtupyN9FpGz2E1qR3rYhUn X-Received: by 10.42.250.132 with SMTP id mo4mr16185119icb.34.1392612431845; Sun, 16 Feb 2014 20:47:11 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id m6sm28275071igx.9.2014.02.16.20.47.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 20:47:10 -0800 (PST) References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> Mime-Version: 1.0 (1.0) In-Reply-To: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B24C7D5F-0958-448F-A552-0EB9B7470B08; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <1D850D2F-4E1F-4958-8EC9-1774A1793C60@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Thoughts on Multi-Symlink Concept Date: Sun, 16 Feb 2014 23:47:07 -0500 To: Perry Hutchison X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-filesystems@freebsd.org" , "freebsd-hackers@freebsd.org" , "jordan.hubbard@gmail.com" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 04:47:12 -0000 --Apple-Mail-B24C7D5F-0958-448F-A552-0EB9B7470B08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That is a rather lovely example. Going a bit beyond my initial thoughts. . .= . this could be really handy if done correctly. For ports, source, object t= ree's . . . obviously bin directories and even lib directories. Call it the p= oor-mans replication system but with some pretty big benifits. My initial thoughts were to just point directly to files, excluding using gl= obing as a way to just include files in a massive config sort of fashion but= if globing comes into play that would be awesome. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Feb 16, 2014, at 0:16, perryh@pluto.rain.com (Perry Hutchison) wrote: >=20 > Jordan Hubbard wrote: >=20 >> Even variant symlinks (/bin -> /${ARCH}/bin), which can expand >> differently depending on the user context, have clearly >> understandable semantics - you know that the symlink is going >> to expand to exactly one file no matter what ARCH is set to. >=20 > s/file/pathname/ >=20 > Depending on what ARCH is set to, the expanision may or may not > point to any actual file (or directory, or ...) --Apple-Mail-B24C7D5F-0958-448F-A552-0EB9B7470B08 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIxNzA0NDcwOFowIwYJKoZIhvcN AQkEMRYEFO+i/qpzwUEtRDWzQNo+7136vkJZMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAgpbqsp7jq5b6fTqsbUlB sr0nQnL56Kh2voMcMg5vAQu5Uj96/+B4i8ckFY9NHViZ/gTN7CO2m5T3RkPI5SXu+iB0oelv5P04 b1NQNathMUerod8c5VFb/9UJgEzr70lKUX3QfH8hN9d9TVLz9kUnBdAeE+Y7mQiL3mjoSzu8xlut dBAJ95y7YbAERzmoYJ7R85CTp+lRkXsyuCcL2O14eWPgbtmXFKCc16B99CTyUj7YjlA46GW8OWWA 7VoTfzDI2zITtZCcpago6HNKzSx40Fo/AB4HYYbHktiIDekZkivCK6PaMq+vO/pFbINm7HpcabhB z8MH+bCHm7fRq03wgwAAAAAAAA== --Apple-Mail-B24C7D5F-0958-448F-A552-0EB9B7470B08-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 09:55:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E476378 for ; Mon, 17 Feb 2014 09:55:35 +0000 (UTC) Received: from nm38.bullet.mail.ne1.yahoo.com (nm38.bullet.mail.ne1.yahoo.com [98.138.229.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E287E1A45 for ; Mon, 17 Feb 2014 09:55:33 +0000 (UTC) Received: from [127.0.0.1] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 09:55:32 -0000 Received: from [98.138.100.117] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 09:52:38 -0000 Received: from [98.139.215.143] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 09:52:38 -0000 Received: from [98.139.212.197] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 09:52:38 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 09:52:38 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 674413.379.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 8480 invoked by uid 60001); 17 Feb 2014 09:52:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392630758; bh=Tirn5ziXV+bms4k8/VloXUUcuwN6oejP0IK7RDBbJy8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=GVCsKii1rUMsu85HqeBZUkm2fxFICl0mAf7pz6e+wprSfiuK4IqMg1h0JyuAzTc95N0YPQ59HMHD11TAvNZMojcuSbCHXae2qyfRmzdT57rmaOXxv99GiP2U2KWQRTQ/pWVQ0jiE2+ULjgDfly/3hfA4dx7Yll6sFIOSbpFXE2E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=QjinP1CoXIxcQIEuzI9TDkmSEpjGyhiRJh+XImlzIDamfLQMX+EkSJOs22gL6Ux5REZ2zBQSpd9Z6h5HfYfG1SYBGDQbum/dzrT6sjC/t/rV4gn+uazGWjeqA6BEHEPDKSrWlydQsZOf4VAMqJI7WdNVmlBk5bSN9hSaBdVtHvE=; X-YMail-OSG: uPJoTfUVM1nj6QwZ83Gu.4xYyfyMw.Wx7RN5KOgVNyNxQK3 _ekPl0ECMuuqWcLjypVoChnqP.pC4oSVmoXuvvxfTFNy2I53o75rTm2XdddM AlmpAHUmHuoTTzy1QCyRvTxD.6LXa2JJ2znjMrXwfjGcB9Ca8R6q.ofUzYmU 8MI1y43PQI2QWEvfhqEx4LMoLjD2mmie7KF1AG2RE1C6HU3vWrWPCEC4ggJW dugl1rhT325U0zy1DIfhNT9JKeePsrDGu8XLxNmqZ.gKKXyjFY2MH7HwyGLE RdQ6_y7zDNfmlEd.eae7z.UH2PEMXAQYAEo37KIzx6tZw0tG9ECHSSMa0zXB E4sOFTbIo1kYOQTqW5Bx5Qll97I0JxVoS9y8Ba5XqnFNwvkGU0LoOfUP0PAY USk_W9OE5.tP2bUTk9utTfJXEoKqJpgkeCy_hZX8CFdJJR4.g6fKiUl5JLcf 7HMKkqG3LH6mNx3MzY0FDCdg1ScgymTmizvt0zMiWZJRb1oA6bUcUQEHBEHG nuPKzR.Q9_1DrcO7Y3OpElOzcSfm6kZz_fONFXeIOxCwOPeO8YA-- Received: from [89.165.120.140] by web162704.mail.bf1.yahoo.com via HTTP; Mon, 17 Feb 2014 01:52:38 PST X-Rocket-MIMEInfo: 002.001, SGkKUmVjZW50bHkgSSd2ZSBjdXN0b21pemVkIG15IGtlcm5lbCBhbmQgZGVsZXRlZCBtb3N0IG9mIHVudXNlZCBkZXZpY2VzIGFuZCBvcHRpb25zLiBXaGVuIEkgdHJ5IHRvIGNyZWF0ZSBhIGEgZ3JlIGludGVyZmFjZSBJIGdldCB0aGlzIGVycm9yOiAKCgppZmNvbmZpZzogc2lvY2lmY3JlYXRlMjogaW52YWxpZCBhcmd1bWVudAoKSSdtIHVzaW5nIEZyZWVCU0Q5LjIgQU1EIDY0CgpXaGF0J3MgdGhlIHByb2JsZW0_ATABAQEB X-Mailer: YahooMailWebService/0.8.177.636 Message-ID: <1392630758.77600.YahooMailNeo@web162704.mail.bf1.yahoo.com> Date: Mon, 17 Feb 2014 01:52:38 -0800 (PST) From: Nomad Esst Subject: ifconfig siocifcreate invalid argument To: "freebsd-drivers@freebsd.org" , "freebsd-hackers@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Nomad Esst List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:55:35 -0000 Hi Recently I've customized my kernel and deleted most of unused devices and options. When I try to create a a gre interface I get this error: ifconfig: siocifcreate2: invalid argument I'm using FreeBSD9.2 AMD 64 What's the problem? From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 10:15:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 723BED56 for ; Mon, 17 Feb 2014 10:15:49 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0F191C59 for ; Mon, 17 Feb 2014 10:15:48 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Mon, 17 Feb 2014 11:10:39 +0100 id 005080C2.5301E01F.00001B77 Date: Mon, 17 Feb 2014 11:10:35 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: ifconfig siocifcreate invalid argument Message-ID: <20140217111035.328baa3f@zeta.dino.sk> In-Reply-To: <1392630758.77600.YahooMailNeo@web162704.mail.bf1.yahoo.com> References: <1392630758.77600.YahooMailNeo@web162704.mail.bf1.yahoo.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i386-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Nomad Esst X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:15:49 -0000 On Mon, 17 Feb 2014 01:52:38 -0800 (PST) Nomad Esst wrote: > Hi > Recently I've customized my kernel and deleted most of unused devices > and options. When I try to create a a gre interface I get this error: > > > ifconfig: siocifcreate2: invalid argument > > I'm using FreeBSD9.2 AMD 64 > > What's the problem? > If you do not have 'device gre' in kernel config and module if_gre is not loaded automatically, you need to do it yourself - just use 'kldload if_gre' before you try to create interface greN. Regards, Milan From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 10:25:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DA13FB7 for ; Mon, 17 Feb 2014 10:25:53 +0000 (UTC) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 833301CFE for ; Mon, 17 Feb 2014 10:25:52 +0000 (UTC) Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 10:25:48 -0000 Received: from [98.138.226.178] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 10:22:53 -0000 Received: from [98.139.215.140] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 10:22:53 -0000 Received: from [98.139.212.225] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 10:22:53 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 10:22:53 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 599396.47954.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 25153 invoked by uid 60001); 17 Feb 2014 10:22:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392632573; bh=0+EoYiBK/bcDeGuXd2ajkiS8VP2VvkGNWUbVlHFLldg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=t5YasypHCx61nejdv9hV1zYF7XJn8MMEOCQiPCCv9wJXc2j2HXZWYITwWj9Tite/cuEUQCGDdGNG7NXucQ1Ms9yUU0actn5s7wYnd6eB2ytdwktVurFEtCayFzr+YgLHt4fTb7CKjrwV8mmtFLOs8k7HKcwxfNCzS+nJz9rkyPE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1lq2cRCB8sFu21t78Z+90LwH9ytwUpfOol/odPUZfC+XuZwbvIE7My+b3qqHXI+uIrGkogZfm7IvfcyndVjertXxIEmmf+SKAtZ+vgifj/fDDje56N7Evv7wCuV70rylZCMsab4Tkr/mgByhyBeRh+HHy9jr6mMaNC/Ul7NjsPU=; X-YMail-OSG: JSrqBycVM1kzWFm4xtEuQICqOo7plLeV48qNv4mxIy4x271 ficMbi_sE8bJTh2QN4hPfOWqBS1sPdnDB78nSJAGcPPnuxqsg4ORoxOl6UBJ Z1Np.qj_4zGJXjZkR2BhLuNv3ZqP4RAe0n4oWp8tCk_27C4oUUMd5P7dzdtj xK0gNthqxj5khQvo44BiaJ4KdI0VwHYwS7tJDYUE__w7z8P7skQhOTSG7uAX kliTuQ0J2wweQLa__muoZvO.5BGD3RIkuF9qKDWiUxqHhwbdhKMM.ax0c.92 QuvqpDM1rQFEv2QP6iNWpXuzj5UHBk0DAM5QY1_iMf83S0tvkM1_2biyyOq2 _jCYWbhttb71anDti_0IH8sZ3cCH2g8xPCdhTyJSYB_wlpLw2l73HdUOwoez IV3boNTagZP6pVTHHET7ssTds9O2cKEiogilXokrp2wNB9KENx7P9m4NYiuL w5O5Jszw1c_CYvGIveKJ2wThADPWuPWEDyj_yprWGFlb9Zd3pylCW0XEqGrf wY90WzyjGUOb4Y97.EAZASsthc0ZpluO9FJn.ETehbDoFBRZ_iA-- Received: from [89.165.120.140] by web162705.mail.bf1.yahoo.com via HTTP; Mon, 17 Feb 2014 02:22:53 PST X-Rocket-MIMEInfo: 002.001, VGhhbmtzCkRvIHlvdSBrbm93IHdoaWNoIGtlcm5lbCBtb2R1bGUgc2hvdWxkIGJlIGluY2x1ZGVkIGluIGtlcm5lbCBjb25maWcgZmlsZT8gU2luY2Ugd2UgY291bGQgY3JlYXRlIGdyZSBpbnRlcmZhY2VzIHdpdGhvdXQgYW55IHByb2JsZW1zIGJlZm9yZSB3ZSBjdXN0b21pemUgdGhlIGtlcm5lbC4KCgoKCgpPbiBNb25kYXksIEZlYnJ1YXJ5IDE3LCAyMDE0IDE6NDAgUE0sIE1pbGFuIE9idWNoIDxmcmVlYnNkLWhhY2tlcnNAZGluby5zaz4gd3JvdGU6CiAKT24gTW9uLCAxNyBGZWIgMjAxNCAwMTo1MjozOCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1392630758.77600.YahooMailNeo@web162704.mail.bf1.yahoo.com> <20140217111035.328baa3f@zeta.dino.sk> Message-ID: <1392632573.91721.YahooMailNeo@web162705.mail.bf1.yahoo.com> Date: Mon, 17 Feb 2014 02:22:53 -0800 (PST) From: Nomad Esst Subject: Re: ifconfig siocifcreate invalid argument To: Milan Obuch , "freebsd-hackers@freebsd.org" In-Reply-To: <20140217111035.328baa3f@zeta.dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Nomad Esst List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:25:53 -0000 Thanks Do you know which kernel module should be included in kernel config file? Since we could create gre interfaces without any problems before we customize the kernel. On Monday, February 17, 2014 1:40 PM, Milan Obuch wrote: On Mon, 17 Feb 2014 01:52:38 -0800 (PST) > >Nomad Esst wrote: > >> Hi >> Recently I've customized my kernel and deleted most of unused devices >> and options. When I try to create a a gre interface I get this error: >> >> >> ifconfig: siocifcreate2: invalid argument >> >> I'm using FreeBSD9.2 AMD 64 >> >> What's the problem? >> > >If you do not have 'device gre' in kernel config and module if_gre is >not loaded automatically, you need to do it yourself - just use >'kldload if_gre' before you try to create interface greN. > >Regards, >Milan > > > > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 13:06:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD5ED443 for ; Mon, 17 Feb 2014 13:06:28 +0000 (UTC) Received: from mailhost.netlab.sk (mailhost.netlab.sk [84.245.65.10]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 731351E0A for ; Mon, 17 Feb 2014 13:06:27 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlab.sk with ESMTPA; Mon, 17 Feb 2014 14:06:28 +0100 id 00DA25BA.53020954.00002DC8 Date: Mon, 17 Feb 2014 14:06:25 +0100 From: Milan Obuch To: Nomad Esst Subject: Re: ifconfig siocifcreate invalid argument Message-ID: <20140217140625.7f18d14f@zeta.dino.sk> In-Reply-To: <1392632573.91721.YahooMailNeo@web162705.mail.bf1.yahoo.com> References: <1392630758.77600.YahooMailNeo@web162704.mail.bf1.yahoo.com> <20140217111035.328baa3f@zeta.dino.sk> <1392632573.91721.YahooMailNeo@web162705.mail.bf1.yahoo.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i386-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.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:06:28 -0000 On Mon, 17 Feb 2014 02:22:53 -0800 (PST) Nomad Esst wrote: > Thanks > Do you know which kernel module should be included in kernel config > file? Since we could create gre interfaces without any problems > before we customize the kernel. > Well, no idea - I just try and did not see this error on any system here, checked on 9.2-STABLE/amd64 as well, all with minimal kernel config (no network card in kernel, no SCSI adapter in kernel, no sound card in kernel etc.) and every time if_gre kernel module was loaded correctly when 'ifconfig gre0 create' command was issued in shell. Maybe your ifconfig needs to be rebuilt if you have not build system and binaries from the same sources, but no other idea here... Also, in my sources I did not find 'device gre' in kernel either, so I am not sure if this possibility even exists, but you can try it just to be sure... > On Monday, February 17, 2014 1:40 PM, Milan Obuch > wrote: > On Mon, 17 Feb 2014 01:52:38 -0800 (PST) > > > >Nomad Esst wrote: > > > >> Hi > >> Recently I've customized my kernel and deleted most of unused > >> devices and options. When I try to create a a gre interface I get > >> this error: > >> > >> > >> ifconfig: siocifcreate2: invalid argument > >> > >> I'm using FreeBSD9.2 AMD 64 > >> > >> What's the problem? > >> > > > >If you do not have 'device gre' in kernel config and module if_gre is > >not loaded automatically, you need to do it yourself - just use > >'kldload if_gre' before you try to create interface greN. > > > >Regards, > >Milan > > Milan From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 17 13:31:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8C82FFF for ; Mon, 17 Feb 2014 13:31:41 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AA0F11CB for ; Mon, 17 Feb 2014 13:31:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=WGGs+diODDj/94ZwM2p4gstwJgYmu22gHiWqeGqdO4s=; b=YmIgFIr7aCrj1umYWrsgPdn47dNa3q/T5PVD7Rwo7w2iyL3CavoBxPfhRFuWZ3FZJgSRIEUa6pJutGpXxKNAoUBVZy6M+Aslvg7XB3yHAzb5RsXfxTUfeux5SzVpYJ1XuohgRUGSlj/TbkpiHKbqOEKosVToNFUfxFeAElonsfM=; Received: from [39.221.151.185] (port=29272 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFOIH-004A9Z-Dh; Mon, 17 Feb 2014 06:31:34 -0700 Date: Mon, 17 Feb 2014 21:31:27 +0800 From: Erich Dollansky To: Milan Obuch Subject: Re: ifconfig siocifcreate invalid argument Message-ID: <20140217213127.41281a83@X220.alogt.com> In-Reply-To: <20140217140625.7f18d14f@zeta.dino.sk> References: <1392630758.77600.YahooMailNeo@web162704.mail.bf1.yahoo.com> <20140217111035.328baa3f@zeta.dino.sk> <1392632573.91721.YahooMailNeo@web162705.mail.bf1.yahoo.com> <20140217140625.7f18d14f@zeta.dino.sk> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, Nomad Esst X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:31:41 -0000 Hi, On Mon, 17 Feb 2014 14:06:25 +0100 Milan Obuch wrote: > On Mon, 17 Feb 2014 02:22:53 -0800 (PST) > Nomad Esst wrote: > > > Thanks > > Do you know which kernel module should be included in kernel config > > file? Since we could create gre interfaces without any problems > > before we customize the kernel. > > > > Well, no idea - I just try and did not see this error on any system > here, checked on 9.2-STABLE/amd64 as well, all with minimal kernel > config (no network card in kernel, no SCSI adapter in kernel, no sound > card in kernel etc.) and every time if_gre kernel module was loaded > correctly when 'ifconfig gre0 create' command was issued in shell. my observation is that if the kernel contains a certain module A which required module B to run, module B is not loaded. Stripping all modules which might be required out of the kernel and then get them loaded later will show with kldstat whet modules have been loaded. Of course, modules not needed yet are not shown. If there is no comment in GENERIC, it is a bit of trial and error to find the modules needed. Erich From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 18 07:29:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCF3779E; Tue, 18 Feb 2014 07:29:22 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29E7015F5; Tue, 18 Feb 2014 07:29:21 +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 s1I7SLFO087426; Tue, 18 Feb 2014 07:28:21 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s1I7SLBK087425; Tue, 18 Feb 2014 07:28:21 GMT (envelope-from wkoszek) Date: Tue, 18 Feb 2014 07:28:21 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: BSD XXI Manifesto Message-ID: <20140218072821.GF34282@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 18 Feb 2014 07:28:25 +0000 (UTC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 07:29:23 -0000 (cross-posted message: eventual discussion let's keep on hackers@) Hello, After being disappointed with the list of submitted FreeBSD ideas, I created my own Machiavellist vision of XXI-century FreeBSD. I paste it below. If you want to add something, it's here: https://wiki.freebsd.org/BSD_XXI_Manifesto GSOC students could use this as an inspiration for their projects. The idea is to invite non-C, non-OS, non-kernel developers to help out with FreeBSD stuff. ============ BSDXXI manifesto For people seeking for inspiration here are some ideas of how FreeBSD of 21st century could operate... - FreeBSD boots from simple USB-stick image or SD card. Image would contain nothing more than HTTP-enabled installer, so that as OS updates are rolled out, the installer doesn't change. It means I can keep the same USB-stick for years, since all packages/installation procedure would actually be fetched from the Internet. - installer is in high-resolution mode with graphical environment started, and my bluetooth/remote-USB mouse/keyboard working OK. Additionally I have an access to the filesystem on USB-stick. I have Wi-Fi access and/or Ethernet access and a browser to do the installation. This all is in case I want to bother to use a keyboard. - installer starts HTTP server in the background. It serves responsive 'FreeBSD installer' website. You can enter this website with your smartphone and perform the whole installation procedure from your mobile device. This HTTP server is getting left of "service partition", so that in case of problems, you can always boot FreeBSD in emergency mode and recover from problems. - installer asks me whether I'd like to use my FreeBSD account or to setup one. FreeBSD is similar to Apple ID or Amazon ID and remembers my preferences, so that in case of installation/backup/recovery I don't have to be asked same questions 10 times. This data is stored in an encrypted form on my disk, and gets imported by all programs that may ever want to ask me about my name/surname etc. This account is used to submit data about hardware which I use too, so that developers see which hardware is popular among users. This account is used for encrypted crashdump reports, bug reporting and others. This is the key to the contact with the FreeBSD developers community. Also as a part of the account users get easy access to 'BSDDEV' environment, which lets them clone, change and contribute back changes by themselves, without asking any commiters/developers for anything. They may later request this change to be pushed back to the FreeBSD. - installer asks me whether I'd like to pick certain profile of installation and install everything in 1 step. This is similar to "1 click buy" on Amazon, and is similar to node.js "npm" manager -- dozens of users contribute their installation profiles to the FreeBSD portal, and FreeBSD accounts have access to these profiles. Everybody sees which installation profile has most "Likes", and based on that users can choose whether to struggle with 100 parameters for the installation, or pick something that expert picked for them. Also desktop users willing to use Flash can pick "freebsd_superflash" installation profile, which will give them Flash working out of the box etc... - Among installation profiles, installer presents me: * mobile installation (cell phone) FreeBSD of XXI century runs on most of mobile devices, and this is one of the types of installation which I can pick for my tablet/smartphone. FreeBSD found great adoption in mobile environments, since BSD license attracted more people than GPLv4 code. FreeBSD has drivers for all sensors, GPSes and GSM/UMTS modules from phones. * laptop This profile installs me all possible optimizations for maximal power and maximal battery life, and minimal noise for any leftover laptops that still have a fan. * desktop This profile installs me everything for a desktop user. * VM (cloud solution: EC2, Rackspace etc) This installation may pick optimized I/O schedulers, so that environments which charge for I/O access, network access etc.. end up being cheap thanks to smart algorithms in FreeBSD. * hosted cloud This is a profile for enterprise users. Hosted installation is something which lets you designate a master, and slaves which connect to the master. Once slaves are connected, from 1 installer you can choose what all nodes will get installed and how they'll work. So e.g.: if you want to have a storage-cloud with 4 servers, you can make them be a redundant storage with 2 servers each, for improved efficiency. If servers are plugged in the same switch, I'd like to see them all in the menu and be able to toggle the ones which I want to be added to the cluster. - FreeBSD is getting setup in less than 5 minutes. All stages are marked with barcodes/URLs, so that in case of problems, user can take a photo of a screen and get immediate helps from FreeBSD community portal. - FreeBSD on 1st boot establishes connection via your FreeBSD ID and submits stuff necessary for improved FreeBSD development. You may choose not to submit stuff, but you'll not get an access to interactive bug database, easy contribution capability etc.. - FreeBSD ID offers to sync my disk with the BSDCloud, and offers me options for storage providers and their prices. - FreeBSD once installed, just works. It includes only the most necessary ports installed as a part of chosen profile. If necessary, users can share their configurations, e.g.: if there's somebody who got Jail/MAC/Capability-enabled environment for Node.Js installed in /jail/nodejs/, I don't really want to keep retyping his commands like a monkey. I just want to get his configuration and 20s is max I can wait for this to happen. This includes things which are popular, but boring, e.g.: HTTP server, SQL server, Mail server etc.. configuration. I'd like to add my 3 domains: koszek.com freebsd.czest.pl something.com to FreeBSD system, pick my HTTP solution, my Mail solution, my SQL solution and have them installed in the most security-hardened way possible with 0 effort. - I keep all of important system actions versioned/logged, so that if I happen to have some problems with ports/packages, I can send the journal of what happened to my system, so that somebody can reproduce it. - in cases of problems with programs, I screen share my terminal with other FreeBSD IDs. I'd like to say: "I want FreeBSD ID 'cognet' to have access to this computer but only for watching", so that I can show the problem to the 2nd FreeBSD developer. It should also be possible to give full-access to the machine to the developer, so that in case of critical problems developer can reproduce exactly what's going on. - FreeBSD rarely asks me to compile anything. FreeBSD.org has powerful BSDCloud configuration which compiles everything for me. So if I want custom kernel configuration, I can mark checkboxes online and BSDCloud will compile the kernel quickly for me, so that I don't have to bother with it. - In case of problems, it's very easily to submit a record. FreeBSD loader, FreeBSD kernel and FreeBSD user-space utilities are all equiped with OCR-enabled/scannable mechanism, which lets me to use my phone to submit a bug report. It should be possible to e.g.: take a photo of a screen, have your phone recognize what the photo is all about and act accordingly via your FreeBSD ID (submit benchmark result, submit bug report, submit security problem etc..) - FreeBSD developers check in stuff to the repository. Upon check-in FreeBSD gets compiled and automatically booted on all possible platforms -- where possible in the BSDCloud, and where it's not possible, it gets booted on real hardware. Developer has access to the BSDCloud, so should the problem happen, the VM is frozen and dev. can login to it and see what's wrong. - Upon each commit FreeBSD regression test suite is run. Test suite tries to make sure FreeBSD is still runnable, and whether any regressions got introduced. Each unit test lets you to start, stop and modify existing VM by typing commands in it and comparing the result the expected one. Users can easily contribute to regression tests by recording their actions and contributing the recorded sessions back: their FreeBSD IDs can submit regression sets to the repository and their tests will be included in the next regression run. - FreeBSD documentation is always up-to-date. Regression suite is basically a specialized Domain Specific Language, that is especially annotated with comments which are an integral part of the code. This code is used to generate the documentation -- upon each action the screenshot is taken and explanation gets inserted. Once regression test is run, and screenshots are obtained, they get glued together for a slide-show (HTML page) or screencast and are being exported to YouTube. - Check-in process gets modified, so that only when all accepted regression sets are run, the check-in is accepted. - Documentation is available in easy-to-modify form for all FreeBSD IDs. Internal format for the documentation doesn't matter, since everything gets edited in the WWW browser anyway. - Once the document is submitted, it gets reviewed and accepted by the FreeBSD developer. Upon commit, all FreeBSD IDs whose users marked 'want to contribute to documentation' get the notification on document change. The ones which speak other languages get a chance to translate the changes right away and earn credits. - submission of regression test/patch/doc change earns FreeBSD ID certain reputation. FreeBSD ID could get tied to FreeBSD forums, so that people who help others a lot also get credits. There's a simple 'acceptance' formula: above X credits you get privileges A, B, C within FreeBSD.org. - FreeBSD development can happen entirely online, via BSDCould. Users and developers can edit files via WWW browser and do it the same way. They compile the system and boot it in VM and later, on the real hardware. - Upon making a change, I select 'users who have device X' and users who marked the checkbox 'Willing to test'. They get the VM which I used for testing available and can clone the VM's configuration to their system with 1 click, boot on their hardware and report the results. - Donation process gets modified so that users who care about certain devices a lot can send their hardware to BSDCloud. Hardware would get plugged in the physical hardware and since then regression tests testing this piece of hardware would be run on each commit. Expensive hardware can get linked with BSDCloud so that the machine stays on the owners side. This box is available via VPN just like any other BSDCloud box, and as long as it's available, regression suite is run on it as well. VPN works across firewall and proxies, so specialized platforms behind the corporate walls can also get tested. - On each commit set of benchmarks is run and visualized in the browser. The configuration can include the VM configurations, but can also involve hardware. So before performing a change, developer can see the impact of the change on the system performance. - On each commit set of power benchmarks is run. Couple of real hardware setups have power measurement attached to them and are able to export power profiling information upon commit. This is crucial for cell phones, which FreeBSD can run. ============ -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 18 18:09:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E743BF55 for ; Tue, 18 Feb 2014 18:09:40 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7831F12A8 for ; Tue, 18 Feb 2014 18:09:39 +0000 (UTC) Received: from mobile.client (192.133.167.190.d.dyn.codetel.net.do [190.167.133.192] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1II6q83057170; Tue, 18 Feb 2014 19:06:57 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1II6k11070595; Tue, 18 Feb 2014 19:06:48 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1II6kX3070594; Tue, 18 Feb 2014 19:06:46 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Date: Tue, 18 Feb 2014 19:06:46 +0100 From: Andre Albsmeier To: freebsd-hackers@freebsd.org Subject: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140218180646.GA67861@schlappy> 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: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean Cc: mail@ma17.ata.myota.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:09:41 -0000 Well, as these are my first steps regarding thread programming, it's probably my fault... Why does this programme slowly grow and grow until it hits resource limits? ----- snip pth1.c ----- #include #include #include void* mythread( void* arg ) { return NULL; } int main( int argc, const char* const argv[] ) { pthread_t pthr; int i; while( 1 ) { for( i=1000; i; i-- ) if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) fprintf( stderr, "pthread_create\n" ); else pthread_detach( pthr ); putchar( '.' ); fflush( stdout ); usleep( 25000 ); } } ----- snap ----- Just to be sure I have also created the non-detaching version which behaves in the same way: ----- snip pth2.c ----- #include #include #include #define M 1000 pthread_t pthr[M]; void* mythread( void* arg ) { return NULL; } int main( int argc, const char* const argv[] ) { int i; while( 1 ) { for( i=M; i; i-- ) if( pthread_create( &pthr[i], NULL, mythread, NULL ) != 0 ) fprintf( stderr, "pthread_create\n" ); for( i=M; i; i-- ) if( pthread_join( pthr[i], NULL ) != 0 ) fprintf( stderr, "pthread_join\n" ); putchar( '.' ); fflush( stdout ); usleep( 25000 ); } } ----- snap ----- Compile them using -pthread and watch their ps output in another window (FreeBSD-9.2 but that shouldn't matter). So what am I doing wrong here? Thanks, -Andre From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 18 19:21:36 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E46B3FB1; Tue, 18 Feb 2014 19:21:36 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7219919B4; Tue, 18 Feb 2014 19:21:36 +0000 (UTC) Received: from mobile.client (192.133.167.190.d.dyn.codetel.net.do [190.167.133.192] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1IJLTaP057557; Tue, 18 Feb 2014 20:21:32 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1IJLJ2X086289; Tue, 18 Feb 2014 20:21:24 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1IJLJSm086288; Tue, 18 Feb 2014 20:21:19 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Date: Tue, 18 Feb 2014 20:21:19 +0100 From: Andre Albsmeier To: symbolics@gmx.com Subject: Re: GEOM mentor request Message-ID: <20140218192119.GA86251@schlappy> References: <20131101103158.GA35397@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101103158.GA35397@lemon> X-Echelon: NCSA, F-15, TWA, secret, Minox X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean Cc: geom@freebsd.org, hackers@freebsd.org, mail@ma17.ata.myota.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:21:37 -0000 On Fri, 01-Nov-2013 at 10:31:58 +0000, symbolics@gmx.com wrote: > Hi hackers, > > I have been studying the GEOM documentation and source recently. Is > anyone actively maintaining this subsystem at the moment? I would like > to give it some attention. A few example things I'd like to work on (in > no particular order): > ... > + Probably other bits I can't remember right now. Well, in case you are looking for a probably easy task: Teach gstripe and geli about TRIM as it was done with gmirror in http://svnweb.freebsd.org/base?view=revision&revision=237930 http://svnweb.freebsd.org/base?view=revision&revision=237929 I wanted to have a look a this since more than one year now but time never permitted it (and that's why I am replying to your message after more than 3 months ;-)). -Andre From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 18 19:58:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A65EA8FE; Tue, 18 Feb 2014 19:58:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74C761D67; Tue, 18 Feb 2014 19:58:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 911BBB93B; Tue, 18 Feb 2014 14:58:23 -0500 (EST) From: John Baldwin To: Andrey Chernov Subject: Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code? Date: Tue, 18 Feb 2014 14:42:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140215001100.GS34851@funkthat.com> <52FED14E.50304@freebsd.org> In-Reply-To: <52FED14E.50304@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201402181442.36380.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 14:58:23 -0500 (EST) Cc: "freebsd-hackers@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:58:24 -0000 On Friday, February 14, 2014 9:30:38 pm Andrey Chernov wrote: > On 15.02.2014 4:11, John-Mark Gurney wrote: > >>> This is code example from cpuminer port, in case you are interested, it is very simple: > >>> > >>> static inline void affine_to_cpu(int id, int cpu) > >>> { > >>> cpuset_t set; > >>> CPU_ZERO(&set); > >>> CPU_SET(cpu, &set); > >>> cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_CPUSET, -1, sizeof(cpuset_t), &set); > >> > >> I think that CPU_WHICH_TID should have been used here. > > > > I agree... cpuset(2): > > The which argument determines how the value of id is interpreted and is > > of type cpuwhich_t. The which argument may have the following values: > > > > CPU_WHICH_TID id is lwpid_t (thread id) > > CPU_WHICH_PID id is pid_t (process id) > > CPU_WHICH_CPUSET id is a cpusetid_t (cpuset id) > > CPU_WHICH_IRQ id is an irq number > > > > An id of '-1' may be used with a which of CPU_WHICH_TID, CPU_WHICH_PID, > > or CPU_WHICH_CPUSET to mean the current thread, process, or current > > thread's cpuset. All cpuset syscalls allow this usage. > > The question still remains: why SCHED_ULE and SCHED_4BSD do different > things here on CPU_WHICH_CPUSET == -1 (current thread's cpuset)? It > looks like SCHED_ULE changes per/process mask while SCHED_4BSD change > per/thread mask in that case. Eh, no. CPU_WHICH_CPUSET changes the global set that the thread belongs to. t is not per proceses or per thread. Unless you are explicitly creating new global sets, your thread belongs to the default set (set 1), and this call is changing the default set (set 1) to only use a single CPU. This affects all processes in the machine that do not have their own sets. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 14:35:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B96B8BD for ; Wed, 19 Feb 2014 14:35:26 +0000 (UTC) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19AB91C54 for ; Wed, 19 Feb 2014 14:35:25 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id d10so407086eaj.32 for ; Wed, 19 Feb 2014 06:35:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W0US+w0x6u6POCX2XTbaBmHCHIP5dBWyf5nzM/WiwuA=; b=H1jA+dcI+ztaGUYXVNytudK2W4hWm7AmShKAyQyIJuqianynAuyiUaZVtqaJTp8ADb OcoJF2BkBLtUQx0h6R1M6DagS5KcGKX0Dfmu2w7mogaeh18Q1+BXFnvXCwZbxInHD1xi R0gjnxS1Wv5smNXXAOXOuapiu5bHgh48tzgmRsykGqANM/ciidfOrep6uln+PGQKgEY0 sTINyK2BzSbG97uwtMLUj7thIu+5y3n3uNl1KQMNRaNWM22CafCmxNn7T/GjHXAADBRN 2PXAS/ND3YNWSKVQNkA9+B7WPvGsUPZW8U5sXuLozq+wZ2H0ozm3l9tzmels5bI2eqUf t43Q== X-Gm-Message-State: ALoCoQldK7ZZJcik9ax3vMUHsAKOnAsyJSXbIQlnZnsjYYvlcM4rNjiNWJGI/IMNNsas2WYmZN5w X-Received: by 10.15.98.68 with SMTP id bi44mr15243103eeb.67.1392820143279; Wed, 19 Feb 2014 06:29:03 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id j42sm1290703eep.21.2014.02.19.06.29.02 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 06:29:02 -0800 (PST) Message-ID: <5304BFAD.50502@freebsd.org> Date: Wed, 19 Feb 2014 18:29:01 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code? References: <20140215001100.GS34851@funkthat.com> <52FED14E.50304@freebsd.org> <201402181442.36380.jhb@freebsd.org> In-Reply-To: <201402181442.36380.jhb@freebsd.org> X-Enigmail-Version: 1.7a1pre Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 14:35:26 -0000 On 18.02.2014 23:42, John Baldwin wrote: > Eh, no. CPU_WHICH_CPUSET changes the global set that the thread belongs to. > t is not per proceses or per thread. Unless you are explicitly creating > new global sets, your thread belongs to the default set (set 1), and this > call is changing the default set (set 1) to only use a single CPU. This > affects all processes in the machine that do not have their own sets. > Thanx for detailed explanation. According to it, SCHED_ULE does the right thing for such CPU_WHICH_CPUSET call, while SCHED_4BSD does not. Is recent r260043 supposed to fix the problem for SCHED_4BSD or is it unrelated? I can't check it by myself yet. -- http://ache.vniz.net/ From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 14:47:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72126E56; Wed, 19 Feb 2014 14:47:42 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id D88621D31; Wed, 19 Feb 2014 14:47:41 +0000 (UTC) Received: from mobile.client (177.189.166.190.f.sta.codetel.net.do [190.166.189.177] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1JElZoj064223; Wed, 19 Feb 2014 15:47:37 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1JElS4B003075; Wed, 19 Feb 2014 15:47:29 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1JElS5L003074; Wed, 19 Feb 2014 15:47:28 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Date: Wed, 19 Feb 2014 15:47:28 +0100 From: Andre Albsmeier To: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140219144728.GA3036@schlappy> References: <20140218180646.GA67861@schlappy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140218180646.GA67861@schlappy> X-Echelon: 757, CIO, secure, Tower, SWAT X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean Cc: mail@ma17.ata.myota.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 14:47:42 -0000 [Commenting my own mail from below and CC'ing freebsd-threads.] I have tested my code below on a Linux box (3.2.0) and here the behaviour is different and seems correct: While watching with top(1), VIRT climbs up to a few GB and collapses then to a few MB (somehow reminding me of some kind of garbage collection). Important thing is that RES always stays below 1MB. On FreeBSD SIZE and RES are about 100MB apart but both are increasing util 2GB and pth1 dies with Cannot map anonymous memory Out of memory So the question is: Is my programme buggy and Linux works around this bug or is there some kind of memory leak in the pthreads code in FreeBSD? -Andre ----- Forwarded message ----- Well, as these are my first steps regarding thread programming, it's probably my fault... Why does this programme slowly grow and grow until it hits resource limits? ----- snip pth1.c ----- #include #include #include void* mythread( void* arg ) { return NULL; } int main( int argc, const char* const argv[] ) { pthread_t pthr; int i; while( 1 ) { for( i=1000; i; i-- ) if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) fprintf( stderr, "pthread_create\n" ); else pthread_detach( pthr ); putchar( '.' ); fflush( stdout ); usleep( 25000 ); } } ----- snap ----- Just to be sure I have also created the non-detaching version which behaves in the same way: ----- snip pth2.c ----- #include #include #include #define M 1000 pthread_t pthr[M]; void* mythread( void* arg ) { return NULL; } int main( int argc, const char* const argv[] ) { int i; while( 1 ) { for( i=M; i; i-- ) if( pthread_create( &pthr[i], NULL, mythread, NULL ) != 0 ) fprintf( stderr, "pthread_create\n" ); for( i=M; i; i-- ) if( pthread_join( pthr[i], NULL ) != 0 ) fprintf( stderr, "pthread_join\n" ); putchar( '.' ); fflush( stdout ); usleep( 25000 ); } } ----- snap ----- Compile them using -pthread and watch their ps output in another window (FreeBSD-9.2 but that shouldn't matter). So what am I doing wrong here? Thanks, -Andre From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 15:08:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B958D6B; Wed, 19 Feb 2014 15:08:34 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 31DAA108C; Wed, 19 Feb 2014 15:08:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=r2BurpOF7RHq+4+fPAPU4MSaKWX+ZIxYpP0sHV0sbW8=; b=vjeSb0vc/viWwRfyfO0J9+rV4y5V/gtNz9nLtinU8ddCL8efsPQnwvpXqRuW8yLBruXYovQh+PHqQ3/GB551Ckdqclkdpp1msteVDkauMiVznjL68QwaXUqeY/l98m26srxGwG8Y2giKzdXgrSYuiZCrdvwOYV2MoBDIoV4BdBI=; Received: from [39.212.216.37] (port=15745 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WG8lC-002Ag6-N2; Wed, 19 Feb 2014 08:08:32 -0700 Date: Wed, 19 Feb 2014 23:08:24 +0800 From: Erich Dollansky To: Andre Albsmeier Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140219230824.0f2ba24b@X220.alogt.com> In-Reply-To: <20140219144728.GA3036@schlappy> References: <20140218180646.GA67861@schlappy> <20140219144728.GA3036@schlappy> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:08:34 -0000 Hi, as I understand your program, it creates 1000 threads, waits a but and then starts again creating 1000 threads until something kill it.=20 =46rom my point of view, your program depends very much on the default settings of the environment. If the environment allows the immediate execution of the new thread, you will never get many threads. Otherwise, the number of threads hanging around could add up. It also depends on the number of CPUs/cores your system has. But your are right, it should not crash on a modern machine but it still could use some amount of memory. Erich On Wed, 19 Feb 2014 15:47:28 +0100 Andre Albsmeier wrote: > [Commenting my own mail from below and CC'ing freebsd-threads.] >=20 > I have tested my code below on a Linux box (3.2.0) and here the > behaviour is different and seems correct: While watching with > top(1), VIRT climbs up to a few GB and collapses then to a few > MB (somehow reminding me of some kind of garbage collection). > Important thing is that RES always stays below 1MB. >=20 > On FreeBSD SIZE and RES are about 100MB apart but both are > increasing util 2GB and pth1 dies with=20 >=20 > Cannot map anonymous memory > Out of memory >=20 > So the question is: Is my programme buggy and Linux works around > this bug or is there some kind of memory leak in the pthreads > code in FreeBSD? >=20 > -Andre >=20 > ----- Forwarded message ----- >=20 > Well, as these are my first steps regarding thread programming, > it's probably my fault... >=20 > Why does this programme slowly grow and grow until it hits > resource limits? >=20 > ----- snip pth1.c ----- >=20 > #include > #include > #include >=20 > void* mythread( void* arg ) > { > return NULL; > } >=20 > int main( int argc, const char* const argv[] ) > { > pthread_t pthr; > int i; >=20 > while( 1 ) { >=20 > for( i=3D1000; i; i-- ) > if( pthread_create( &pthr, NULL, mythread, NULL ) !=3D 0 ) > fprintf( stderr, "pthread_create\n" ); > else > pthread_detach( pthr ); >=20 > putchar( '.' ); > fflush( stdout ); > usleep( 25000 ); > } > } >=20 > ----- snap ----- >=20 > Just to be sure I have also created the non-detaching version > which behaves in the same way: >=20 > ----- snip pth2.c ----- >=20 > #include > #include > #include >=20 > #define M 1000 >=20 > pthread_t pthr[M]; >=20 > void* mythread( void* arg ) > { > return NULL; > } >=20 > int main( int argc, const char* const argv[] ) > { > int i; >=20 > while( 1 ) { >=20 > for( i=3DM; i; i-- ) > if( pthread_create( &pthr[i], NULL, mythread, NULL ) !=3D 0 ) > fprintf( stderr, "pthread_create\n" ); >=20 > for( i=3DM; i; i-- ) > if( pthread_join( pthr[i], NULL ) !=3D 0 ) > fprintf( stderr, "pthread_join\n" ); >=20 > putchar( '.' ); > fflush( stdout ); > usleep( 25000 ); > } > } >=20 > ----- snap ----- >=20 > Compile them using -pthread and watch their ps output in another > window (FreeBSD-9.2 but that shouldn't matter). >=20 > So what am I doing wrong here? >=20 > Thanks, >=20 > -Andre > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 15:29:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65FF4668; Wed, 19 Feb 2014 15:29:45 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id E1CEE127E; Wed, 19 Feb 2014 15:29:43 +0000 (UTC) Received: from mobile.client (177.189.166.190.f.sta.codetel.net.do [190.166.189.177] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1JFTcoh064412; Wed, 19 Feb 2014 16:29:40 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1JFTWmn003381; Wed, 19 Feb 2014 16:29:32 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1JFTWq9003380; Wed, 19 Feb 2014 16:29:32 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Date: Wed, 19 Feb 2014 16:29:32 +0100 From: Andre Albsmeier To: Erich Dollansky Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140219152932.GA3324@schlappy> References: <20140218180646.GA67861@schlappy> <20140219144728.GA3036@schlappy> <20140219230824.0f2ba24b@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140219230824.0f2ba24b@X220.alogt.com> X-Echelon: Colonel, Surveillance, secret, Satellite, Uzi X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Andre Albsmeier , freebsd-threads@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:29:45 -0000 On Wed, 19-Feb-2014 at 23:08:24 +0800, Erich Dollansky wrote: > Hi, > > as I understand your program, it creates 1000 threads, waits a but and > then starts again creating 1000 threads until something kill it. Right. 1000 threads are started, do nothing and thus terminate immediately. The value of 25 ms for usleep is just a good one for my machine to demonstrate the problem quickly while being sure that all 1000 threads have gone (verified with ps -H). You can chose a bigger value here and it will just take more time... > > From my point of view, your program depends very much on the default > settings of the environment. If the environment allows the immediate > execution of the new thread, you will never get many threads. > Otherwise, the number of threads hanging around could add up. It also > depends on the number of CPUs/cores your system has. But I never have more than 1000 threads. This is why I made pth2 where I explicitly wait for all 1000 threads to terminate before firing up the next bunch. So for me it seems as if every (already died away) thread leaves some memory behind which does not get free'ed or whatever. But it was my understanding that pthread_detach() or pthread_join() would clean all this up after a thread has finished. > > But your are right, it should not crash on a modern machine but it > still could use some amount of memory. But should it still grow with every bunch of 1000 threads being started while the previous 1000 are all gone already? I'd agree if the behaviour was like on the Linux machine where it seems that some kind of garbage collection kicks in for VIRT after a while but RES never goes above 1MB there. On FreeBSD it even makes the box swap... -Andre > > Erich > > On Wed, > 19 Feb 2014 15:47:28 +0100 Andre Albsmeier > wrote: > > > [Commenting my own mail from below and CC'ing freebsd-threads.] > > > > I have tested my code below on a Linux box (3.2.0) and here the > > behaviour is different and seems correct: While watching with > > top(1), VIRT climbs up to a few GB and collapses then to a few > > MB (somehow reminding me of some kind of garbage collection). > > Important thing is that RES always stays below 1MB. > > > > On FreeBSD SIZE and RES are about 100MB apart but both are > > increasing util 2GB and pth1 dies with > > > > Cannot map anonymous memory > > Out of memory > > > > So the question is: Is my programme buggy and Linux works around > > this bug or is there some kind of memory leak in the pthreads > > code in FreeBSD? > > > > -Andre > > > > ----- Forwarded message ----- > > > > Well, as these are my first steps regarding thread programming, > > it's probably my fault... > > > > Why does this programme slowly grow and grow until it hits > > resource limits? > > > > ----- snip pth1.c ----- > > > > #include > > #include > > #include > > > > void* mythread( void* arg ) > > { > > return NULL; > > } > > > > int main( int argc, const char* const argv[] ) > > { > > pthread_t pthr; > > int i; > > > > while( 1 ) { > > > > for( i=1000; i; i-- ) > > if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) > > fprintf( stderr, "pthread_create\n" ); > > else > > pthread_detach( pthr ); > > > > putchar( '.' ); > > fflush( stdout ); > > usleep( 25000 ); > > } > > } > > > > ----- snap ----- > > > > Just to be sure I have also created the non-detaching version > > which behaves in the same way: > > > > ----- snip pth2.c ----- > > > > #include > > #include > > #include > > > > #define M 1000 > > > > pthread_t pthr[M]; > > > > void* mythread( void* arg ) > > { > > return NULL; > > } > > > > int main( int argc, const char* const argv[] ) > > { > > int i; > > > > while( 1 ) { > > > > for( i=M; i; i-- ) > > if( pthread_create( &pthr[i], NULL, mythread, NULL ) != 0 ) > > fprintf( stderr, "pthread_create\n" ); > > > > for( i=M; i; i-- ) > > if( pthread_join( pthr[i], NULL ) != 0 ) > > fprintf( stderr, "pthread_join\n" ); > > > > putchar( '.' ); > > fflush( stdout ); > > usleep( 25000 ); > > } > > } > > > > ----- snap ----- > > > > Compile them using -pthread and watch their ps output in another > > window (FreeBSD-9.2 but that shouldn't matter). > > > > So what am I doing wrong here? > > > > Thanks, > > > > -Andre > > _______________________________________________ > > freebsd-threads@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > > To unsubscribe, send any mail to > > "freebsd-threads-unsubscribe@freebsd.org" > > -- echo "cdec cdec efg~ efg~ L8gagfL4ec L8gagfL4ec cc~ cc~" >/dev/speaker From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 15:30:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 128E477D; Wed, 19 Feb 2014 15:30:57 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E609412E4; Wed, 19 Feb 2014 15:30:56 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id C584B1A3C38; Wed, 19 Feb 2014 07:30:53 -0800 (PST) Message-ID: <5304CE2C.1060305@mu.org> Date: Wed, 19 Feb 2014 07:30:52 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Erich Dollansky , Andre Albsmeier Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) References: <20140218180646.GA67861@schlappy> <20140219144728.GA3036@schlappy> <20140219230824.0f2ba24b@X220.alogt.com> In-Reply-To: <20140219230824.0f2ba24b@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:30:57 -0000 On 2/19/14 7:08 AM, Erich Dollansky wrote: > Hi, > > as I understand your program, it creates 1000 threads, waits a but and > then starts again creating 1000 threads until something kill it. > > From my point of view, your program depends very much on the default > settings of the environment. If the environment allows the immediate > execution of the new thread, you will never get many threads. > Otherwise, the number of threads hanging around could add up. It also > depends on the number of CPUs/cores your system has. > > But your are right, it should not crash on a modern machine but it > still could use some amount of memory. OK. Maybe use a global locked with a mutex or atomic that gets increased each time the main thread spawns a thread and then decreased by that thread right before the child thread exits. Then the main loop can print the value of that. If it gets huge then your main loop is making threads faster than the system can remove them. If not , then it's a leak. > > Erich > > On Wed, > 19 Feb 2014 15:47:28 +0100 Andre Albsmeier > wrote: > >> [Commenting my own mail from below and CC'ing freebsd-threads.] >> >> I have tested my code below on a Linux box (3.2.0) and here the >> behaviour is different and seems correct: While watching with >> top(1), VIRT climbs up to a few GB and collapses then to a few >> MB (somehow reminding me of some kind of garbage collection). >> Important thing is that RES always stays below 1MB. >> >> On FreeBSD SIZE and RES are about 100MB apart but both are >> increasing util 2GB and pth1 dies with >> >> Cannot map anonymous memory >> Out of memory >> >> So the question is: Is my programme buggy and Linux works around >> this bug or is there some kind of memory leak in the pthreads >> code in FreeBSD? >> >> -Andre >> >> ----- Forwarded message ----- >> >> Well, as these are my first steps regarding thread programming, >> it's probably my fault... >> >> Why does this programme slowly grow and grow until it hits >> resource limits? >> >> ----- snip pth1.c ----- >> >> #include >> #include >> #include >> >> void* mythread( void* arg ) >> { >> return NULL; >> } >> >> int main( int argc, const char* const argv[] ) >> { >> pthread_t pthr; >> int i; >> >> while( 1 ) { >> >> for( i=1000; i; i-- ) >> if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) >> fprintf( stderr, "pthread_create\n" ); >> else >> pthread_detach( pthr ); >> >> putchar( '.' ); >> fflush( stdout ); >> usleep( 25000 ); >> } >> } >> >> ----- snap ----- >> >> Just to be sure I have also created the non-detaching version >> which behaves in the same way: >> >> ----- snip pth2.c ----- >> >> #include >> #include >> #include >> >> #define M 1000 >> >> pthread_t pthr[M]; >> >> void* mythread( void* arg ) >> { >> return NULL; >> } >> >> int main( int argc, const char* const argv[] ) >> { >> int i; >> >> while( 1 ) { >> >> for( i=M; i; i-- ) >> if( pthread_create( &pthr[i], NULL, mythread, NULL ) != 0 ) >> fprintf( stderr, "pthread_create\n" ); >> >> for( i=M; i; i-- ) >> if( pthread_join( pthr[i], NULL ) != 0 ) >> fprintf( stderr, "pthread_join\n" ); >> >> putchar( '.' ); >> fflush( stdout ); >> usleep( 25000 ); >> } >> } >> >> ----- snap ----- >> >> Compile them using -pthread and watch their ps output in another >> window (FreeBSD-9.2 but that shouldn't matter). >> >> So what am I doing wrong here? >> >> Thanks, >> >> -Andre >> _______________________________________________ >> freebsd-threads@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-threads >> To unsubscribe, send any mail to >> "freebsd-threads-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > -- Alfred Perlstein From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 15:53:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C820144; Wed, 19 Feb 2014 15:53:05 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B49151569; Wed, 19 Feb 2014 15:53:04 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id x13so758901qcv.6 for ; Wed, 19 Feb 2014 07:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LojqmoGwSaJXOshXdbS7hU+6Q+ODcxN2ZcE1RtagsTM=; b=UA/d/woNjPZunaVim3CtOU9KF3hxcZxNdT+5WnPPbpbKicAtI09MjH0sFDsLzM9J6k LR2UUVhgHBte7RydRAaQ/k5oPLjZkuLru9tOIsGLeVk30nVext6nnyLEapaxk4stCFwk CczCcAgkPcPkT6veP6sVbap1qK2Fihk5OJvUwgvUqyIlAMcQA94JZ1ch0uFm2FAFgYzH B+VDw3ZZTxpQnzciQJpSobiCMDuauGytFF+9DeK6UBbZB3JvMFxcxA7cDWJaze/5RD/B fpymv7mO5NEhF4/bNd3+yqDStkhWXLIo/so98eGAiAQKgdWy4QMoPXynxNIGs0dMZJZ9 C+Pw== MIME-Version: 1.0 X-Received: by 10.140.23.52 with SMTP id 49mr47830537qgo.17.1392825183925; Wed, 19 Feb 2014 07:53:03 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.140.31.68 with HTTP; Wed, 19 Feb 2014 07:53:03 -0800 (PST) In-Reply-To: <20140219230824.0f2ba24b@X220.alogt.com> References: <20140218180646.GA67861@schlappy> <20140219144728.GA3036@schlappy> <20140219230824.0f2ba24b@X220.alogt.com> Date: Wed, 19 Feb 2014 10:53:03 -0500 X-Google-Sender-Auth: 1fP6CbASp3MqYFUsCHtCwlsb_4M Message-ID: Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) From: Ed Maste To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Andre Albsmeier , freebsd-threads@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:53:05 -0000 On 19 February 2014 10:08, Erich Dollansky wrote: > Hi, > > as I understand your program, it creates 1000 threads, waits a but and > then starts again creating 1000 threads until something kill it. > > From my point of view, your program depends very much on the default > settings of the environment. If the environment allows the immediate > execution of the new thread, you will never get many threads. > Otherwise, the number of threads hanging around could add up. It also > depends on the number of CPUs/cores your system has. > But your are right, it should not crash on a modern machine but it > still could use some amount of memory. Andre's second example program demonstrates the problem as well. It calls pthread_join() for each of the created threads, so should not be able to leave them around. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 16:24:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF198E9E; Wed, 19 Feb 2014 16:24:59 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 508241870; Wed, 19 Feb 2014 16:24:58 +0000 (UTC) Received: from mobile.client (177.189.166.190.f.sta.codetel.net.do [190.166.189.177] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1JGOmb4065093; Wed, 19 Feb 2014 17:24:52 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1JGOfDw003648; Wed, 19 Feb 2014 17:24:42 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1JGOfDj003647; Wed, 19 Feb 2014 17:24:41 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Date: Wed, 19 Feb 2014 17:24:41 +0100 From: Andre Albsmeier To: Alfred Perlstein Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140219162441.GA3564@schlappy> References: <20140218180646.GA67861@schlappy> <20140219144728.GA3036@schlappy> <20140219230824.0f2ba24b@X220.alogt.com> <5304CE2C.1060305@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5304CE2C.1060305@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Erich Dollansky , Andre Albsmeier , freebsd-threads@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:24:59 -0000 On Wed, 19-Feb-2014 at 07:30:52 -0800, Alfred Perlstein wrote: > On 2/19/14 7:08 AM, Erich Dollansky wrote: > > Hi, > > > > as I understand your program, it creates 1000 threads, waits a but and > > then starts again creating 1000 threads until something kill it. > > > > From my point of view, your program depends very much on the default > > settings of the environment. If the environment allows the immediate > > execution of the new thread, you will never get many threads. > > Otherwise, the number of threads hanging around could add up. It also > > depends on the number of CPUs/cores your system has. > > > > But your are right, it should not crash on a modern machine but it > > still could use some amount of memory. > OK. Maybe use a global locked with a mutex or atomic that gets > increased each time the main thread spawns a thread and then decreased > by that thread right before the child thread exits. > Then the main loop can print the value of that. > > If it gets huge then your main loop is making threads faster than the > system can remove them. If not , then it's a leak. While my second programme (pth2) explicitly waits for all threads to terminate, I tried what you suggested and here is the result (although these are my first steps w.r.t. threads I think I did it correctly ;-)): ----- snip ----- #include #include #include #define THREADS 1000 int c = 0; pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER; void* mythread( void* arg ) { pthread_mutex_lock( &mtx ); c--; pthread_mutex_unlock( &mtx ); return NULL; } int main( int argc, const char* const argv[] ) { pthread_t pthr; int i; while( 1 ) { pthread_mutex_lock( &mtx ); c += THREADS; pthread_mutex_unlock( &mtx ); for( i=THREADS; i; i-- ) if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) fprintf( stderr, "pthread_create\n" ); else pthread_detach( pthr ); pthread_mutex_lock( &mtx ); fprintf( stderr, "%d:", c ); pthread_mutex_unlock( &mtx ); usleep( 25000 ); pthread_mutex_lock( &mtx ); fprintf( stderr, "%d ", c ); pthread_mutex_unlock( &mtx ); } } ----- snap ----- As we can see, I print c before the usleep() and after, both values separated by a colon. One of the results is here (after running it through fmt(1)): 1:0 0:0 1:0 0:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 0:0 1:0 1:0 1:0 1:0 1:0 322:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 126:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 16:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 131:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 66:0 1:0 98:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 132:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 18:0 1:0 1:0 1:0 1:0 1:0 1:0 123:0 1:0 1:0 1:0 1:0 1:0 1:0 24:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 146:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 121:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 3:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 125:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 52:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 7:0 1:0 1:0 1:0 2:0 1:0 573:0 1:0 1:0 1:0 1:0 1:0 1:0 465:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 19:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:0 1:^C We can see that in most case one thread is still active before the usleep() but after that all are gone. In rare cases there are hundreds active but they will be gone for sure after the usleep()... But apart from that we might stick to pth2.c as this definitely waits for all threads to terminate. I'd also be interested to know how pth2 behaves on FreeBSD boxes other than 9.2... -Andre > > > > > > Erich > > > > On Wed, > > 19 Feb 2014 15:47:28 +0100 Andre Albsmeier > > wrote: > > > >> [Commenting my own mail from below and CC'ing freebsd-threads.] > >> > >> I have tested my code below on a Linux box (3.2.0) and here the > >> behaviour is different and seems correct: While watching with > >> top(1), VIRT climbs up to a few GB and collapses then to a few > >> MB (somehow reminding me of some kind of garbage collection). > >> Important thing is that RES always stays below 1MB. > >> > >> On FreeBSD SIZE and RES are about 100MB apart but both are > >> increasing util 2GB and pth1 dies with > >> > >> Cannot map anonymous memory > >> Out of memory > >> > >> So the question is: Is my programme buggy and Linux works around > >> this bug or is there some kind of memory leak in the pthreads > >> code in FreeBSD? > >> > >> -Andre > >> > >> ----- Forwarded message ----- > >> > >> Well, as these are my first steps regarding thread programming, > >> it's probably my fault... > >> > >> Why does this programme slowly grow and grow until it hits > >> resource limits? > >> > >> ----- snip pth1.c ----- > >> > >> #include > >> #include > >> #include > >> > >> void* mythread( void* arg ) > >> { > >> return NULL; > >> } > >> > >> int main( int argc, const char* const argv[] ) > >> { > >> pthread_t pthr; > >> int i; > >> > >> while( 1 ) { > >> > >> for( i=1000; i; i-- ) > >> if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) > >> fprintf( stderr, "pthread_create\n" ); > >> else > >> pthread_detach( pthr ); > >> > >> putchar( '.' ); > >> fflush( stdout ); > >> usleep( 25000 ); > >> } > >> } > >> > >> ----- snap ----- > >> > >> Just to be sure I have also created the non-detaching version > >> which behaves in the same way: > >> > >> ----- snip pth2.c ----- > >> > >> #include > >> #include > >> #include > >> > >> #define M 1000 > >> > >> pthread_t pthr[M]; > >> > >> void* mythread( void* arg ) > >> { > >> return NULL; > >> } > >> > >> int main( int argc, const char* const argv[] ) > >> { > >> int i; > >> > >> while( 1 ) { > >> > >> for( i=M; i; i-- ) > >> if( pthread_create( &pthr[i], NULL, mythread, NULL ) != 0 ) > >> fprintf( stderr, "pthread_create\n" ); > >> > >> for( i=M; i; i-- ) > >> if( pthread_join( pthr[i], NULL ) != 0 ) > >> fprintf( stderr, "pthread_join\n" ); > >> > >> putchar( '.' ); > >> fflush( stdout ); > >> usleep( 25000 ); > >> } > >> } > >> > >> ----- snap ----- > >> > >> Compile them using -pthread and watch their ps output in another > >> window (FreeBSD-9.2 but that shouldn't matter). > >> > >> So what am I doing wrong here? > >> > >> Thanks, > >> > >> -Andre > >> _______________________________________________ > >> freebsd-threads@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-threads > >> To unsubscribe, send any mail to > >> "freebsd-threads-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-threads@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > > > > -- > Alfred Perlstein > -- Stuxnet? Find ich gut. Manche lernen nur auf die harte Tour... From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 19 16:52:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87A0BE0C; Wed, 19 Feb 2014 16:52:47 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 329B51B68; Wed, 19 Feb 2014 16:52:47 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so1151077qgd.1 for ; Wed, 19 Feb 2014 08:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9ZiijEZEsJSOC1EaFiT39Lg3SZbZTDYrMjgc5HyA5gs=; b=drAMunIHj68LradsofqLTvaqXHiOpBu4J3Xr2+pW712EqlSi8lfPDdKUa0HnrdVA8b tly0ATMU90Mun9+4KJvv68CMVQ/vk4f/haWKKu0Cn54J4YfRhSVXnIeJi+la25qw8Nol uXLVlQSSVxxH3YoD9fwekLKA/0VgbBLeBn2WsMIG0HvXR+lVeb1dTm4cArRah5igVNya x8K8mgFhAGDH4guncS1g8NYx7NDOP3czPywggGkHIz3sQI8szF5FVzZ5mhnx9LHaHRXl dab2lLalc4pQLKOCH2/jHWWDO5PRp9wncILWcxOFlAQNpNrZUTiouky431ZtIhvQIzKn 5y2Q== MIME-Version: 1.0 X-Received: by 10.224.114.78 with SMTP id d14mr2781415qaq.19.1392828766359; Wed, 19 Feb 2014 08:52:46 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.140.31.68 with HTTP; Wed, 19 Feb 2014 08:52:46 -0800 (PST) In-Reply-To: <20140219162441.GA3564@schlappy> References: <20140218180646.GA67861@schlappy> <20140219144728.GA3036@schlappy> <20140219230824.0f2ba24b@X220.alogt.com> <5304CE2C.1060305@mu.org> <20140219162441.GA3564@schlappy> Date: Wed, 19 Feb 2014 11:52:46 -0500 X-Google-Sender-Auth: sZr8r4zDLYiKWc8YN1wY2augiY0 Message-ID: Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) From: Ed Maste To: Andre Albsmeier Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Erich Dollansky , Alfred Perlstein , freebsd-threads@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:52:47 -0000 On 19 February 2014 11:24, Andre Albsmeier wrote: > I'd also be interested to know how pth2 behaves on FreeBSD boxes > other than 9.2... It is reproducible on FreeBSD-CURRENT from about 2 weeks ago; it looks like we probably do have an issue in libthr. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 20 01:29:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E05287CC for ; Thu, 20 Feb 2014 01:29:55 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B69BA19B1 for ; Thu, 20 Feb 2014 01:29:55 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kp14so1199752pab.9 for ; Wed, 19 Feb 2014 17:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=k3TWaqWyhA3uJuIEjmXSVeOjE8g9AwS/kahl3OsdBB0=; b=UTDFcgWMMgHzfMWGjCI6axTT8iDQx0s7FkrgpVOFHuqUssKyAocg43shXbN+XPuiyh fgvpAbvJiXnSHBVBoyNby5dfUm/v1OREVB6AIneRDhtwzJ8sKF5VKBoxN7TL+YKgUmgF N8x0120E+ecjtzVesLvWV22ifFnAFxIE/CTI+U8cEXVaFNFxJEXfU1u5HUqMuZ6AS+Xw XzNAn/+d7m/29uNXRb1elUeWTI3qYde1KNDf2ED6IrbM7+qDvmkpXn0idjFjUdmun/2J 1RFuzpFfCixjKnJ9U5mflj8HVpaIoZnnV5WX4QMJrzmz+IWYrCrNVzsAQ8ulGBiXayPH gxtw== X-Received: by 10.69.31.235 with SMTP id kp11mr43212321pbd.36.1392859795385; Wed, 19 Feb 2014 17:29:55 -0800 (PST) Received: from [10.51.2.103] ([199.101.130.202]) by mx.google.com with ESMTPSA id yh4sm4964598pbb.19.2014.02.19.17.29.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 17:29:54 -0800 (PST) From: George Kola Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Question about ZFS arc cache and page cache Message-Id: Date: Wed, 19 Feb 2014 17:29:52 -0800 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:29:55 -0000 I have a question about what happens when a file on a ZFS filesystem is = mmaped into memory. I traced it on illumos and found that the file pages = made it into the ARC cache and then I got a copy of it in page cache = which was then mapped to my address space. Another process mapping the = same file got the same page from the page cache. (I used mdb and = converting virtual address to physical address to see if the pages were = the same) . I was wondering if FreeBSD does the same copy or if the physical pages = in ARC can be used for mmap without requiring a copy. The reason for = this question is that we are currently on illumos and are considering = moving to FreeBSD and are evaluating the pros and cons. Thanks, George From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 20 03:39:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A715059E; Thu, 20 Feb 2014 03:39:20 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7BD9F1850; Thu, 20 Feb 2014 03:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=yre7YymE+a8m2Vg/eil5/04v5d3NrHpt+xAzof75zV4=; b=m7k/cvOPFziIj1Lq9k6QCG88JmE3SoZZa0j3bp0ekiSkvjkzPWPsbnNdvL6ObZXEoCCu05h7iR95cC0PGNUbYIUqKQME1VGwlDON7w9f/W45vCLQW48jFruqbBix4yqjLPJCnsspyhJdCOSdBvORPnA3RGvhqKk1XBG+pGEXq3E=; Received: from [39.199.31.111] (port=10635 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGKTd-003x4N-Ri; Wed, 19 Feb 2014 20:39:11 -0700 Date: Thu, 20 Feb 2014 11:39:02 +0800 From: Erich Dollansky To: Andre Albsmeier Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140220113902.63e97b00@X220.alogt.com> In-Reply-To: <20140219162441.GA3564@schlappy> References: <20140218180646.GA67861@schlappy> <20140219144728.GA3036@schlappy> <20140219230824.0f2ba24b@X220.alogt.com> <5304CE2C.1060305@mu.org> <20140219162441.GA3564@schlappy> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, Alfred Perlstein , freebsd-threads@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 03:39:20 -0000 Hi, On Wed, 19 Feb 2014 17:24:41 +0100 Andre Albsmeier wrote: I am now running this program: > #include > #include > #include > > #define THREADS 1000 > > int c = 0; > pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER; > > void* mythread( void* arg ) > { > pthread_mutex_lock( &mtx ); > c--; > pthread_mutex_unlock( &mtx ); > > return NULL; > } > > int main( int argc, const char* const argv[] ) > { > pthread_t pthr; > int i; > > while( 1 ) { > > pthread_mutex_lock( &mtx ); > c += THREADS; > pthread_mutex_unlock( &mtx ); > > for( i=THREADS; i; i-- ) > if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) > fprintf( stderr, "pthread_create\n" ); > else > pthread_detach( pthr ); > > pthread_mutex_lock( &mtx ); > fprintf( stderr, "%d:", c ); > pthread_mutex_unlock( &mtx ); > > usleep( 25000 ); > > pthread_mutex_lock( &mtx ); > fprintf( stderr, "%d ", c ); > pthread_mutex_unlock( &mtx ); > } > } It runs on an i7 with two cores plus two hyper threads. The machine has 8GB of RAM and 16GB of Swap. The resident part of the program stays below 8GB (what wonder) but the rest is swapped out. I run this program on 10.0 from some 2 weeks ago. As already said, it looks like there stays some memory left after a thread terminates. To say something positive, the program really cleaned the memory. Erich From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 20 05:40:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31C881A1 for ; Thu, 20 Feb 2014 05:40:34 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C61B13DF; Thu, 20 Feb 2014 05:40:34 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1K5eWPh076193; Thu, 20 Feb 2014 05:40:33 GMT (envelope-from davidxu@freebsd.org) Message-ID: <53059574.8090605@freebsd.org> Date: Thu, 20 Feb 2014 13:41:08 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andre Albsmeier , freebsd-hackers@freebsd.org Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) References: <20140218180646.GA67861@schlappy> In-Reply-To: <20140218180646.GA67861@schlappy> 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.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 05:40:34 -0000 On 2014/02/19 02:06, Andre Albsmeier wrote: > Well, as these are my first steps regarding thread programming, > it's probably my fault... > > Why does this programme slowly grow and grow until it hits > resource limits? > > ----- snip pth1.c ----- > > #include > #include > #include > > void* mythread( void* arg ) > { > return NULL; > } > > int main( int argc, const char* const argv[] ) > { > pthread_t pthr; > int i; > > while( 1 ) { > > for( i=1000; i; i-- ) > if( pthread_create( &pthr, NULL, mythread, NULL ) != 0 ) > fprintf( stderr, "pthread_create\n" ); > else > pthread_detach( pthr ); > > putchar( '.' ); > fflush( stdout ); > usleep( 25000 ); > } > } > > ----- snap ----- > > Just to be sure I have also created the non-detaching version > which behaves in the same way: > > ----- snip pth2.c ----- > > #include > #include > #include > > #define M 1000 > > pthread_t pthr[M]; > > void* mythread( void* arg ) > { > return NULL; > } > > int main( int argc, const char* const argv[] ) > { > int i; > > while( 1 ) { > > for( i=M; i; i-- ) > if( pthread_create( &pthr[i], NULL, mythread, NULL ) != 0 ) > fprintf( stderr, "pthread_create\n" ); > > for( i=M; i; i-- ) > if( pthread_join( pthr[i], NULL ) != 0 ) > fprintf( stderr, "pthread_join\n" ); > > putchar( '.' ); > fflush( stdout ); > usleep( 25000 ); > } > } > > ----- snap ----- > > Compile them using -pthread and watch their ps output in another > window (FreeBSD-9.2 but that shouldn't matter). > > So what am I doing wrong here? > > Thanks, > > -Andre please compile it as static binary and run it, check if the problem still exists, I am hunting the bug, it is not necessary in the libthr because I have not changed its code for a long time. Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 20 06:07:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CBE04AF; Thu, 20 Feb 2014 06:07:02 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7F101653; Thu, 20 Feb 2014 06:07:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=WLxEoePZHEIEA/vApYg8/fw3VejIIEYqsIGyeP9jSZ4=; b=N4PjeaMbTXPaO3Xi9qjaR/e4eCXiNHLNuRi9xtahiBbHZohX6sD3DjtzXmb7mpMMI7EXyy8V+S4qTFYVC1BeSDPtSnrhas0j1v0Aqico6Ils0ndMvdLagXxh9WnQUjju4lB9kRQDCG2mJuASF6QJ757npG5A6E3Nd+RQE3nnZFo=; Received: from [39.199.31.111] (port=37570 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGMmi-000UEB-2b; Wed, 19 Feb 2014 23:07:00 -0700 Date: Thu, 20 Feb 2014 14:06:44 +0800 From: Erich Dollansky To: David Xu Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140220140644.7b1e0074@X220.alogt.com> In-Reply-To: <53059574.8090605@freebsd.org> References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 06:07:02 -0000 Hi, On Thu, 20 Feb 2014 13:41:08 +0800 David Xu wrote: > On 2014/02/19 02:06, Andre Albsmeier wrote: > > please compile it as static binary and run it, check if the > problem still exists, I am hunting the bug, it is not necessary in > the libthr because I have not changed its code for a long time. I just compiled is a static program. The behaviour is now different. The size still grows but much slower while 'res' stays below some 10MB. Size also got stagnant after some 2 min CPU time hanging around 126MB. I am running it on: FreeBSD X220.alogt.com 10.0-STABLE FreeBSD 10.0-STABLE #15 r261342: Sat Feb 1 14:52:39 WITA 2014 erich@X220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 Erich From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 20 08:05:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5333CE9E for ; Thu, 20 Feb 2014 08:05:56 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F4A71086; Thu, 20 Feb 2014 08:05:56 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1K85sHi032465; Thu, 20 Feb 2014 08:05:54 GMT (envelope-from davidxu@freebsd.org) Message-ID: <5305B786.8020708@freebsd.org> Date: Thu, 20 Feb 2014 16:06:30 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> In-Reply-To: <20140220140644.7b1e0074@X220.alogt.com> Content-Type: multipart/mixed; boundary="------------060006050809000708040202" Cc: freebsd-hackers@freebsd.org, Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 08:05:56 -0000 This is a multi-part message in MIME format. --------------060006050809000708040202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2014/02/20 14:06, Erich Dollansky wrote: > Hi, > > On Thu, 20 Feb 2014 13:41:08 +0800 > David Xu wrote: > >> On 2014/02/19 02:06, Andre Albsmeier wrote: >> >> please compile it as static binary and run it, check if the >> problem still exists, I am hunting the bug, it is not necessary in >> the libthr because I have not changed its code for a long time. > > I just compiled is a static program. The behaviour is now different. > The size still grows but much slower while 'res' stays below some 10MB. > > Size also got stagnant after some 2 min CPU time hanging around 126MB. > > I am running it on: > > FreeBSD X220.alogt.com 10.0-STABLE FreeBSD 10.0-STABLE #15 r261342: Sat > Feb 1 14:52:39 WITA 2014 > erich@X220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 > > Erich > I have found the bug, it is in rtld, where malloc_aligned() is misfunctioning, memory can be corrupted by the function. libthr calls _rtld_allocate_tls to allocate tls control block, the function is in rtld, its uses malloc_aligned() which is not working correctly. Patch is attached. Regards, David Xu --------------060006050809000708040202 Content-Type: text/plain; charset=gbk; name="rtld_align_malloc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rtld_align_malloc.diff" Index: libexec/rtld-elf/xmalloc.c =================================================================== --- libexec/rtld-elf/xmalloc.c (revision 260700) +++ libexec/rtld-elf/xmalloc.c (working copy) @@ -72,14 +72,10 @@ malloc_aligned(size_t size, size_t align) { void *mem, *res; - uintptr_t x; - size_t asize, r; - r = round(sizeof(void *), align); - asize = round(size, align) + r; - mem = xmalloc(asize); - x = (uintptr_t)mem; - res = (void *)round(x, align); + mem = xmalloc(size + sizeof(void *) + align - 1); + res =(void*)(((uintptr_t)mem + sizeof(void *) + align - 1) & + ~(align - 1)); *(void **)((uintptr_t)res - sizeof(void *)) = mem; return (res); } --------------060006050809000708040202-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 20 09:00:59 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50774F9A for ; Thu, 20 Feb 2014 09:00:59 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0AF1618 for ; Thu, 20 Feb 2014 09:00:58 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA06032; Thu, 20 Feb 2014 11:00:49 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WGPUv-000OuA-Hb; Thu, 20 Feb 2014 11:00:49 +0200 Message-ID: <5305C404.8010601@FreeBSD.org> Date: Thu, 20 Feb 2014 10:59:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: George Kola , freebsd-hackers@FreeBSD.org Subject: Re: Question about ZFS arc cache and page cache References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:00:59 -0000 on 20/02/2014 03:29 George Kola said the following: > I have a question about what happens when a file on a ZFS filesystem is mmaped into memory. I traced it on illumos and found that the file pages made it into the ARC cache and then I got a copy of it in page cache which was then mapped to my address space. Another process mapping the same file got the same page from the page cache. (I used mdb and converting virtual address to physical address to see if the pages were the same) . > I was wondering if FreeBSD does the same copy or if the physical pages in ARC can be used for mmap without requiring a copy. The reason for this question is that we are currently on illumos and are considering moving to FreeBSD and are evaluating the pros and cons. On FreeBSD the behavior is exactly the same in this respect. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 20 12:16:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7BA7923; Thu, 20 Feb 2014 12:16:29 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 56D4E1903; Thu, 20 Feb 2014 12:16:28 +0000 (UTC) Received: from mobile.client (177.189.166.190.f.sta.codetel.net.do [190.166.189.177] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1KCGBWq071281; Thu, 20 Feb 2014 13:16:16 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1KCG5vO002181; Thu, 20 Feb 2014 13:16:05 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1KCG5qQ002180; Thu, 20 Feb 2014 13:16:05 +0100 (CET) (envelope-from mail@ma17.ata.myota.org) Date: Thu, 20 Feb 2014 13:16:05 +0100 From: Andre Albsmeier To: David Xu Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140220121605.GA2156@schlappy> References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5305B786.8020708@freebsd.org> X-Echelon: Espionage, Osama, codes, AA, eavesdropping X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Erich Dollansky , Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 12:16:30 -0000 On Thu, 20-Feb-2014 at 16:06:30 +0800, David Xu wrote: > On 2014/02/20 14:06, Erich Dollansky wrote: > > Hi, > > > > On Thu, 20 Feb 2014 13:41:08 +0800 > > David Xu wrote: > > > >> On 2014/02/19 02:06, Andre Albsmeier wrote: > >> > >> please compile it as static binary and run it, check if the > >> problem still exists, I am hunting the bug, it is not necessary in > >> the libthr because I have not changed its code for a long time. > > > > I just compiled is a static program. The behaviour is now different. > > The size still grows but much slower while 'res' stays below some 10MB. > > > > Size also got stagnant after some 2 min CPU time hanging around 126MB. > > > > I am running it on: > > > > FreeBSD X220.alogt.com 10.0-STABLE FreeBSD 10.0-STABLE #15 r261342: Sat > > Feb 1 14:52:39 WITA 2014 > > erich@X220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 > > > > Erich > > > > I have found the bug, it is in rtld, where malloc_aligned() is > misfunctioning, memory can be corrupted by the function. > > libthr calls _rtld_allocate_tls to allocate tls control block, > the function is in rtld, its uses malloc_aligned() which is not > working correctly. > > Patch is attached. Your patch seems to have fixed it here on 9.2-STABLE as well. Memory consumption stays at around 9MB RES and 130 MB SIZE for pth2. Thanks! -Andre > > Regards, > David Xu > > Index: libexec/rtld-elf/xmalloc.c > =================================================================== > --- libexec/rtld-elf/xmalloc.c (revision 260700) > +++ libexec/rtld-elf/xmalloc.c (working copy) > @@ -72,14 +72,10 @@ > malloc_aligned(size_t size, size_t align) > { > void *mem, *res; > - uintptr_t x; > - size_t asize, r; > > - r = round(sizeof(void *), align); > - asize = round(size, align) + r; > - mem = xmalloc(asize); > - x = (uintptr_t)mem; > - res = (void *)round(x, align); > + mem = xmalloc(size + sizeof(void *) + align - 1); > + res =(void*)(((uintptr_t)mem + sizeof(void *) + align - 1) & > + ~(align - 1)); > *(void **)((uintptr_t)res - sizeof(void *)) = mem; > return (res); > } -- My other computer is your windows box. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 04:44:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DE2DFA6; Fri, 21 Feb 2014 04:44:30 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7320F1DA8; Fri, 21 Feb 2014 04:44:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=5e2jP2Wn4UIesBMGrWabWpZCCFVS5KexAzzzk+DP7g4=; b=Kk1cYQBYK8Ej2aKONydlQK9+XEUjSExSuJtb82Rxr0gM1pTvru458/vuHpmGjMyOV8rZ0QJ4Bo0U8YCMVJz3gpG9Hxv7SaQk8PwNaVpcrq4pTu8vWDT9KVpuTnGtVrHEcywG7N09lA+9IxDj4a6WFIZo8beSUbidH6R3wKhcp+o=; Received: from [182.9.34.57] (port=31606 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGhyH-003boG-LW; Thu, 20 Feb 2014 21:44:23 -0700 Date: Fri, 21 Feb 2014 12:44:05 +0800 From: Erich Dollansky To: David Xu Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140221124405.0791d375@X220.alogt.com> In-Reply-To: <5305B786.8020708@freebsd.org> References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 04:44:30 -0000 Hi, On Thu, 20 Feb 2014 16:06:30 +0800 David Xu wrote: > On 2014/02/20 14:06, Erich Dollansky wrote: > > I have found the bug, it is in rtld, where malloc_aligned() is > misfunctioning, memory can be corrupted by the function. > > libthr calls _rtld_allocate_tls to allocate tls control block, > the function is in rtld, its uses malloc_aligned() which is not > working correctly. > I installed the patch. It is now much, much better but after hours, something still seems wrong. Size went above 200MB after 40min of CPU time. The number of threads is now above 1200. The machine also has 3 zombies. The machine was restarted some 4h ago. Erich From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 04:57:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98DE82F5 for ; Fri, 21 Feb 2014 04:57:09 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 813D51F6E; Fri, 21 Feb 2014 04:57:09 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1L4v7fR049457; Fri, 21 Feb 2014 04:57:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <5306DCC8.3080001@freebsd.org> Date: Fri, 21 Feb 2014 12:57:44 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> <20140221124405.0791d375@X220.alogt.com> In-Reply-To: <20140221124405.0791d375@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 04:57:09 -0000 On 2014/02/21 12:44, Erich Dollansky wrote: > Hi, > > On Thu, 20 Feb 2014 16:06:30 +0800 > David Xu wrote: > >> On 2014/02/20 14:06, Erich Dollansky wrote: >> >> I have found the bug, it is in rtld, where malloc_aligned() is >> misfunctioning, memory can be corrupted by the function. >> >> libthr calls _rtld_allocate_tls to allocate tls control block, >> the function is in rtld, its uses malloc_aligned() which is not >> working correctly. >> > I installed the patch. It is now much, much better but after hours, > something still seems wrong. Size went above 200MB after 40min of CPU > time. The number of threads is now above 1200. The machine also has 3 > zombies. The machine was restarted some 4h ago. > > Erich > Default thread stack size on 32-bit machine is 1M, if you have 1024 threads, the size can be larger than 1G. I checked maxinum threads kernel allowed is max_threads_per_proc which is 1500 default. So what you have seen might be normal. I don't know what is zombie, is it a zombie process? thread library does not create process. Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 05:15:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B47C55A; Fri, 21 Feb 2014 05:15:32 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A5D5F111D; Fri, 21 Feb 2014 05:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=wgPQpQsBfiGnQ5PCW/SSPW2/V8HIpr8GB2fbKchRH0Q=; b=t30J/bB2KcdqC1b8FdAbZVGrO+kPqLOEu7sRjUAD5gzRYa0WDnAXWSkOBwrpKlBMiwE3aAptHmHPIKd3o2Ons4FPI9dtLgolGTCYNap/cgv5qHysv5sbl814OjMgjV+FRlwQqbDHClA+CKBJKaHv4iAsYx4xz5ZEJTC5UWxBfiQ=; Received: from [182.9.34.57] (port=62645 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGiSP-003qrQ-SL; Thu, 20 Feb 2014 22:15:30 -0700 Date: Fri, 21 Feb 2014 13:15:17 +0800 From: Erich Dollansky To: David Xu Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140221131517.66d5b82c@X220.alogt.com> In-Reply-To: <5306DCC8.3080001@freebsd.org> References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> <20140221124405.0791d375@X220.alogt.com> <5306DCC8.3080001@freebsd.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 05:15:32 -0000 Hi, On Fri, 21 Feb 2014 12:57:44 +0800 David Xu wrote: > On 2014/02/21 12:44, Erich Dollansky wrote: > > On Thu, 20 Feb 2014 16:06:30 +0800 > > David Xu wrote: > > > >> On 2014/02/20 14:06, Erich Dollansky wrote: > >> > >> I have found the bug, it is in rtld, where malloc_aligned() is > >> misfunctioning, memory can be corrupted by the function. > >> > >> libthr calls _rtld_allocate_tls to allocate tls control block, > >> the function is in rtld, its uses malloc_aligned() which is not > >> working correctly. > >> > > I installed the patch. It is now much, much better but after hours, > > something still seems wrong. Size went above 200MB after 40min of > > CPU time. The number of threads is now above 1200. The machine also > > has 3 zombies. The machine was restarted some 4h ago. > > > > Default thread stack size on 32-bit machine is 1M, if you have > 1024 threads, the size can be larger than 1G. I checked > maxinum threads kernel allowed is max_threads_per_proc > which is 1500 default. So what you have seen might be normal. > I don't know what is zombie, is it a zombie process? > thread library does not create process. I know, the zombies do not fit the scenario. Irritating is that some threads stay over. Is it a side effect of the scheduler? I do my normal work with the machine. The load should not block this process for long as I do nothing which requires 100% for all the time. Should I add some code to wait until the counter is zero again and see what is happening then? Erich From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 05:40:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19DD9C90 for ; Fri, 21 Feb 2014 05:40:58 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB4F71324; Fri, 21 Feb 2014 05:40:57 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1L5etlU064374; Fri, 21 Feb 2014 05:40:56 GMT (envelope-from davidxu@freebsd.org) Message-ID: <5306E70D.70402@freebsd.org> Date: Fri, 21 Feb 2014 13:41:33 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> <20140221124405.0791d375@X220.alogt.com> <5306DCC8.3080001@freebsd.org> <20140221131517.66d5b82c@X220.alogt.com> In-Reply-To: <20140221131517.66d5b82c@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 05:40:58 -0000 On 2014/02/21 13:15, Erich Dollansky wrote: > Hi, > > On Fri, 21 Feb 2014 12:57:44 +0800 > David Xu wrote: > >> On 2014/02/21 12:44, Erich Dollansky wrote: >>> On Thu, 20 Feb 2014 16:06:30 +0800 >>> David Xu wrote: >>> >>>> On 2014/02/20 14:06, Erich Dollansky wrote: >>>> >>>> I have found the bug, it is in rtld, where malloc_aligned() is >>>> misfunctioning, memory can be corrupted by the function. >>>> >>>> libthr calls _rtld_allocate_tls to allocate tls control block, >>>> the function is in rtld, its uses malloc_aligned() which is not >>>> working correctly. >>>> >>> I installed the patch. It is now much, much better but after hours, >>> something still seems wrong. Size went above 200MB after 40min of >>> CPU time. The number of threads is now above 1200. The machine also >>> has 3 zombies. The machine was restarted some 4h ago. >>> >> >> Default thread stack size on 32-bit machine is 1M, if you have >> 1024 threads, the size can be larger than 1G. I checked >> maxinum threads kernel allowed is max_threads_per_proc >> which is 1500 default. So what you have seen might be normal. >> I don't know what is zombie, is it a zombie process? >> thread library does not create process. > > I know, the zombies do not fit the scenario. Irritating is that some > threads stay over. Is it a side effect of the scheduler? I do my normal > work with the machine. The load should not block this process for long > as I do nothing which requires 100% for all the time. > I am running your code while playing flash video, and many threads are accumulated, sometimes I saw a peak number at 800 or more, I think it is normal, because the machine is loaded, after usleep returns, other newly created threads may still not have chance to run, and your next loop creates bunch of threads again, it could be very easily to exceed 1000 threads. > Should I add some code to wait until the counter is zero again and see > what is happening then? > Yes, I think so. But thread stacks will be cached by libthr, and never return to free space. so even if there is only one thread, you may see a very large size in top. > Erich > From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 06:05:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 539F05BE; Fri, 21 Feb 2014 06:05:55 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 25ADF14FB; Fri, 21 Feb 2014 06:05:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=G7kNjGIYsD/DnFwe4D3MsyoGNjKeb6nL9Z/ZVeCtj5U=; b=pGxQ+U+yTGS+J2sNPUA1bJjdVOoCpkWg3WlYsMXeWqd5A3e6lx9grfg1rwXld1NZXRYTJyd8DgW5PvdEbYfup4uJQWn/8eZDC2hD6rVSblGXjq7CXPFT9bPVzW9xoyHK9J0oq+dIty/ny4ulurV0h5X/RNzamLQ3KzlDWOjZWZ4=; Received: from [182.9.34.57] (port=37793 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGjFB-004GQs-Tp; Thu, 20 Feb 2014 23:05:54 -0700 Date: Fri, 21 Feb 2014 14:05:41 +0800 From: Erich Dollansky To: David Xu Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140221140541.72020e93@X220.alogt.com> In-Reply-To: <5306E70D.70402@freebsd.org> References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> <20140221124405.0791d375@X220.alogt.com> <5306DCC8.3080001@freebsd.org> <20140221131517.66d5b82c@X220.alogt.com> <5306E70D.70402@freebsd.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 06:05:55 -0000 Hi, On Fri, 21 Feb 2014 13:41:33 +0800 David Xu wrote: > On 2014/02/21 13:15, Erich Dollansky wrote: > > On Fri, 21 Feb 2014 12:57:44 +0800 > > David Xu wrote: > > > I am running your code while playing flash video, and many threads are it is not even my code. I am just interested. > accumulated, sometimes I saw a peak number at 800 or more, I think > it is normal, because the machine is loaded, after usleep returns, > other newly created threads may still not have chance to run, and > your next loop creates bunch of threads again, it could be very > easily to exceed 1000 threads. > > > Should I add some code to wait until the counter is zero again and > > see what is happening then? > > > > Yes, I think so. But thread stacks will be cached by libthr, and never > return to free space. so even if there is only one thread, you may > see a very large size in top. > I first called usleep only of more than 10 threads remained active. Top showed then nicely that this happens sometimes. Since I call usleep only when more than 1000 threads remain active, looks even funnier on top. I added then a loop to the thread and it works smoothly now. It runs now also into problems creating new threads when too many are still running. Of course, the program takes now much more CPU time as it waits less. I think that we can say that the library is not really optimised for empty threads. So, all seems perfect now. Thanks for your work. Erich From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 11:53:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03145FB2 for ; Fri, 21 Feb 2014 11:53:09 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD17813D9 for ; Fri, 21 Feb 2014 11:53:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WGof8-0008D6-31 for freebsd-hackers@freebsd.org; Fri, 21 Feb 2014 12:53:02 +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 ; Fri, 21 Feb 2014 12:53:02 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Feb 2014 12:53:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: ata.4 changes Date: Fri, 21 Feb 2014 12:52:48 +0100 Lines: 63 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="46DflCcuDI4v31cMdTGr70qk4JTCf7qSe" 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:24.0) Gecko/20100101 Thunderbird/24.3.0 X-Enigmail-Version: 1.6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 11:53:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --46DflCcuDI4v31cMdTGr70qk4JTCf7qSe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Can someone who knows more about man pages take a look at this patch to ata.4: Index: ada.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ada.4 (revision 262293) +++ ada.4 (working copy) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 8, 2012 +.Dd February 21, 2014 .Dt ADA 4 .Os .Sh NAME @@ -129,8 +129,14 @@ These variables determines whether device write cache should be enabled globally or per-device or disabled. Set to 1 to enable write cache, 0 to disable, -1 to leave it as-is. -Values modified in runtime take effect only after device reset. -The global default is currently enabled. +Values modified in runtime take effect only after device reset (using +.Xr camcontrol 8 +reset). +Because of that, this setting should be changed in a +.Xr loader 8 +tunable, not in +.Pa /etc/sysctl.conf . +The global default is currently 1. The per-device default is to leave it as-is (follow global setting). .El .Sh FILES - is it according to style and am I using the tags correctly? --46DflCcuDI4v31cMdTGr70qk4JTCf7qSe 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.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlMHPhFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSyH6gCgpJCBPSH0CtHU/6483lDGufL4 LdcAoJhzuIj3ConfIBXcmDTBhhLJXEBe =DFP0 -----END PGP SIGNATURE----- --46DflCcuDI4v31cMdTGr70qk4JTCf7qSe-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 12:11:45 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDF6851C; Fri, 21 Feb 2014 12:11:45 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A1D615E5; Fri, 21 Feb 2014 12:11:45 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s1LCBLP5096674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 21:11:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s1LCBJZY035612; Fri, 21 Feb 2014 21:11:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 21 Feb 2014 21:10:26 +0900 (JST) Message-Id: <20140221.211026.115752007914804800.hrs@allbsd.org> To: ivoras@FreeBSD.org Subject: Re: ata.4 changes From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Feb_21_21_10_26_2014_935)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 21 Feb 2014 21:11:32 +0900 (JST) X-Spam-Status: No, score=-94.3 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 12:11:46 -0000 ----Security_Multipart(Fri_Feb_21_21_10_26_2014_935)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ivan Voras wrote in : iv> Hello, iv> iv> Can someone who knows more about man pages take a look at this patch to iv> ata.4: iv> iv> Index: ada.4 iv> =================================================================== iv> --- ada.4 (revision 262293) iv> +++ ada.4 (working copy) iv> @@ -25,7 +25,7 @@ iv> .\" iv> .\" $FreeBSD$ iv> .\" iv> -.Dd February 8, 2012 iv> +.Dd February 21, 2014 iv> .Dt ADA 4 iv> .Os iv> .Sh NAME iv> @@ -129,8 +129,14 @@ iv> These variables determines whether device write cache should be enabled iv> globally or per-device or disabled. iv> Set to 1 to enable write cache, 0 to disable, -1 to leave it as-is. iv> -Values modified in runtime take effect only after device reset. iv> -The global default is currently enabled. iv> +Values modified in runtime take effect only after device reset (using iv> +.Xr camcontrol 8 iv> +reset). .Pq should be used for (): Values modified in runtime take effect only after device reset .Pq using reset subcommand of Xr camcontrol 8 . iv> +Because of that, this setting should be changed in a iv> +.Xr loader 8 iv> +tunable, not in iv> +.Pa /etc/sysctl.conf . I think /boot/loader.conf is easier to understand: Because of that, this setting should be changed in .Pa /boot/loader.conf , not in .Pa /etc/sysctl.conf . iv> +The global default is currently 1. iv> The per-device default is to leave it as-is (follow global setting). iv> .El iv> .Sh FILES iv> iv> - is it according to style and am I using the tags correctly? -- Hiroki ----Security_Multipart(Fri_Feb_21_21_10_26_2014_935)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlMHQjIACgkQTyzT2CeTzy1vNQCgpK6rErNy8Vwvcd4Mo0hHhDGi j9oAoN8CwQhHf1AiIKA2x72p9aaWfyJY =Vogq -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Feb_21_21_10_26_2014_935)---- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 12:21:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A69C8DA; Fri, 21 Feb 2014 12:21:48 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id ADB96169F; Fri, 21 Feb 2014 12:21:46 +0000 (UTC) Received: from mobile.client (177.189.166.190.f.sta.codetel.net.do [190.166.189.177] (may be forged)) (authenticated bits=128) by mail.myota.org (8.14.7/8.14.7) with ESMTP id s1LCLVAV079789; Fri, 21 Feb 2014 13:21:34 +0100 (CET) (envelope-from andre@albsmeier.net) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.7/8.14.7) with ESMTP id s1LCLM5c002053; Fri, 21 Feb 2014 13:21:23 +0100 (CET) (envelope-from andre@schlappy.albsmeier.net) Received: (from mu@schlappy.local) by schlappy.local (8.14.7/8.14.7/Submit) id s1LCLMTA002052; Fri, 21 Feb 2014 13:21:22 +0100 (CET) (envelope-from andre@schlappy.albsmeier.net) Date: Fri, 21 Feb 2014 13:21:22 +0100 From: Andre Albsmeier To: David Xu Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140221122122.GA2031@schlappy> References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> <20140221124405.0791d375@X220.alogt.com> <5306DCC8.3080001@freebsd.org> <20140221131517.66d5b82c@X220.alogt.com> <5306E70D.70402@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5306E70D.70402@freebsd.org> X-Echelon: Hackers, SDI, Delta, InfoSec, S/Key X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x X-Virus-Scanned: clamav-milter 0.98.1 at colo X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 21 Feb 2014 14:04:06 +0000 Cc: freebsd-hackers@freebsd.org, Erich Dollansky , Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 12:21:48 -0000 On Fri, 21-Feb-2014 at 13:41:33 +0800, David Xu wrote: > On 2014/02/21 13:15, Erich Dollansky wrote: > > Hi, > > > > On Fri, 21 Feb 2014 12:57:44 +0800 > > David Xu wrote: > > > >> On 2014/02/21 12:44, Erich Dollansky wrote: > >>> On Thu, 20 Feb 2014 16:06:30 +0800 > >>> David Xu wrote: > >>> > >>>> On 2014/02/20 14:06, Erich Dollansky wrote: > >>>> > >>>> I have found the bug, it is in rtld, where malloc_aligned() is > >>>> misfunctioning, memory can be corrupted by the function. > >>>> > >>>> libthr calls _rtld_allocate_tls to allocate tls control block, > >>>> the function is in rtld, its uses malloc_aligned() which is not > >>>> working correctly. > >>>> > >>> I installed the patch. It is now much, much better but after hours, > >>> something still seems wrong. Size went above 200MB after 40min of > >>> CPU time. The number of threads is now above 1200. The machine also > >>> has 3 zombies. The machine was restarted some 4h ago. > >>> > >> > >> Default thread stack size on 32-bit machine is 1M, if you have > >> 1024 threads, the size can be larger than 1G. I checked > >> maxinum threads kernel allowed is max_threads_per_proc > >> which is 1500 default. So what you have seen might be normal. > >> I don't know what is zombie, is it a zombie process? > >> thread library does not create process. > > > > I know, the zombies do not fit the scenario. Irritating is that some > > threads stay over. Is it a side effect of the scheduler? I do my normal > > work with the machine. The load should not block this process for long > > as I do nothing which requires 100% for all the time. > > > > I am running your code while playing flash video, and many threads are > accumulated, sometimes I saw a peak number at 800 or more, I think > it is normal, because the machine is loaded, after usleep returns, > other newly created threads may still not have chance to run, and > your next loop creates bunch of threads again, it could be very > easily to exceed 1000 threads. I would like to recall that my usleep programme was just a first shot to demonstrate the problem here on my idle machine. For real work loads the other one (pth2) might be better as this one waits for all threads to terminate before firing up new ones... -Andre > > > Should I add some code to wait until the counter is zero again and see > > what is happening then? > > > > Yes, I think so. But thread stacks will be cached by libthr, and never > return to free space. so even if there is only one thread, you may > see a very large size in top. > > > Erich > > > -- Micro$oft: Which virus will you get today? From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 14:17:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CA18F18; Fri, 21 Feb 2014 14:17:42 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1ECF21302; Fri, 21 Feb 2014 14:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=ulnNUl5MmC7Q4KA+tBRP8fL2p9dAF2pwkityjgBzM94=; b=xtbX5gzbC+2wGSbFTATlKp8Vl5IXPjMJlVnya6aTkzn+h0ryeIvPhzulxn8WQ99Nzbvqm4iz2Xp/WZ2zkASy4utbzk6LI8/y0eeq6ouj/xxu7nqlbz7/ZPZ9+iCWRalz9gvg2xQJO8vsJc1f8wZ8isR5ha6Nj6GLrROzhcZlSdc=; Received: from [182.7.203.218] (port=48801 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGqv6-0044W0-GH; Fri, 21 Feb 2014 07:17:41 -0700 Date: Fri, 21 Feb 2014 22:17:28 +0800 From: Erich Dollansky To: Andre Albsmeier Subject: Re: pthread programming eats up resources (My or FreeBSD's fault?) Message-ID: <20140221221728.5464e035@X220.alogt.com> In-Reply-To: <20140221122122.GA2031@schlappy> References: <20140218180646.GA67861@schlappy> <53059574.8090605@freebsd.org> <20140220140644.7b1e0074@X220.alogt.com> <5305B786.8020708@freebsd.org> <20140221124405.0791d375@X220.alogt.com> <5306DCC8.3080001@freebsd.org> <20140221131517.66d5b82c@X220.alogt.com> <5306E70D.70402@freebsd.org> <20140221122122.GA2031@schlappy> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org, David Xu , Andre Albsmeier X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:17:42 -0000 Hi, On Fri, 21 Feb 2014 13:21:22 +0100 Andre Albsmeier wrote: > On Fri, 21-Feb-2014 at 13:41:33 +0800, David Xu wrote: > > On 2014/02/21 13:15, Erich Dollansky wrote: > I would like to recall that my usleep programme was just a first > shot to demonstrate the problem here on my idle machine. For real > work loads the other one (pth2) might be better as this one waits > for all threads to terminate before firing up new ones... do not worry. It was the perfect thing to demonstrate the problem. We all should be happy for this masterpiece of code. Erich From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 14:51:24 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 520CD606; Fri, 21 Feb 2014 14:51:24 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00C0016FA; Fri, 21 Feb 2014 14:51:23 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1LEpFNj009376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Feb 2014 07:51:15 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1LEpFt6009373; Fri, 21 Feb 2014 07:51:15 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 21 Feb 2014 07:51:15 -0700 (MST) From: Warren Block To: Hiroki Sato Subject: Re: ata.4 changes In-Reply-To: <20140221.211026.115752007914804800.hrs@allbsd.org> Message-ID: References: <20140221.211026.115752007914804800.hrs@allbsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 21 Feb 2014 07:51:15 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org, ivoras@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:51:24 -0000 On Fri, 21 Feb 2014, Hiroki Sato wrote: > Ivan Voras wrote > in : > > iv> Hello, > iv> > iv> Can someone who knows more about man pages take a look at this patch to > iv> ata.4: > iv> > iv> Index: ada.4 > iv> =================================================================== > iv> --- ada.4 (revision 262293) > iv> +++ ada.4 (working copy) > iv> @@ -25,7 +25,7 @@ > iv> .\" > iv> .\" $FreeBSD$ > iv> .\" > iv> -.Dd February 8, 2012 > iv> +.Dd February 21, 2014 > iv> .Dt ADA 4 > iv> .Os > iv> .Sh NAME > iv> @@ -129,8 +129,14 @@ > iv> These variables determines whether device write cache should be enabled Not part of the original change, but since we are here: s/determines/determine/ > iv> globally or per-device or disabled. > iv> Set to 1 to enable write cache, 0 to disable, -1 to leave it as-is. > iv> -Values modified in runtime take effect only after device reset. > iv> -The global default is currently enabled. > iv> +Values modified in runtime take effect only after device reset (using > iv> +.Xr camcontrol 8 > iv> +reset). > > .Pq should be used for (): > > Values modified in runtime take effect only after device reset > .Pq using reset subcommand of Xr camcontrol 8 . > > iv> +Because of that, this setting should be changed in a > iv> +.Xr loader 8 > iv> +tunable, not in > iv> +.Pa /etc/sysctl.conf . > > I think /boot/loader.conf is easier to understand: > > Because of that, this setting should be changed in > .Pa /boot/loader.conf , > not in > .Pa /etc/sysctl.conf . Agreed. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 17:24:29 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3409983D for ; Fri, 21 Feb 2014 17:24:29 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 07F511760 for ; Fri, 21 Feb 2014 17:24:28 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WGtpr-0004fN-RR for freebsd-hackers@FreeBSD.org; Fri, 21 Feb 2014 17:24:28 +0000 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 s1LHOP3g033023 for ; Fri, 21 Feb 2014 10:24:25 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/8ZqBng5anmFk7PcGksoto Subject: What is the precision arg for callout_reset_sbt() and friends? From: Ian Lepore To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 10:24:25 -0700 Message-ID: <1393003465.1145.111.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.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:24:29 -0000 I can't figure out from the code or the manpage what should be passed as the precision argument to the sleep-related functions that take sbintime values. It seems like most existing code passes 0, what effect does that have? What should I pass if precision really matters? What if it doesn't matter at all? Most of the time I want something like a 1ms timeout where it really isn't critical if it turns into 2 or even 5ms. Other times when I say 1ms I really want something close to 1ms. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 20:24:28 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D295989F; Fri, 21 Feb 2014 20:24:28 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9196018E4; Fri, 21 Feb 2014 20:24:26 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6FEB47300A; Fri, 21 Feb 2014 21:26:37 +0100 (CET) Date: Fri, 21 Feb 2014 21:26:37 +0100 From: Luigi Rizzo To: Ian Lepore Subject: Re: What is the precision arg for callout_reset_sbt() and friends? Message-ID: <20140221202637.GC5118@onelab2.iet.unipi.it> References: <1393003465.1145.111.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393003465.1145.111.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:24:28 -0000 On Fri, Feb 21, 2014 at 10:24:25AM -0700, Ian Lepore wrote: > I can't figure out from the code or the manpage what should be passed as > the precision argument to the sleep-related functions that take sbintime > values. It seems like most existing code passes 0, what effect does > that have? What should I pass if precision really matters? What if it > doesn't matter at all? I was one of the people suggesting the addition of a 'precision' argument, the intent being to use it as a hint to help merge events and reduce the number of timer interrupts. Since pre-existing APIs did not have this parameter we used 0 when translating from the old to the new one. If you write something new of course you can express your needs as you suggest below. In practice i think the following issues partly reduce the usefulness of the parameter: - there is no way to express a precision from userspace so anything using select/poll/kqueue will end up with the 'standard' argument; - with large intervals, aggregation is not really a concern: events are likely to be scattered (so little chance of merging) and probably infrequent (so little gain from merging) - with short periodic intervals (where merging might save something), applications would prefer if the interval is reasonably accurate and has no drift. So I would expect to see a lot of precision=0 in clients of this type. - the implementation, for a delay D and precision P, seems to schedule a timeout after D+P unless one exists already in the interval D..D+P. This increases the chance of merging but is annoying for applications. I think we should do it differently i.e.: if nothing is scheduled in D..D+P then schedule a timeout after D (and not D+P). Then, in the data structure we should (hopefully it is already like this) keep both D and P so when we grab the next event from the timeout queue, we try to set the timer to a value that includes the largest number of intervals, using one of the D_i values (so that at least someone will get it close to the request). This might require a slightly different data structure than the timing wheel/heap or whatever is used now as a backend. cheers luigi > Most of the time I want something like a 1ms timeout where it really > isn't critical if it turns into 2 or even 5ms. Other times when I say > 1ms I really want something close to 1ms. > > -- Ian > > > _______________________________________________ > 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 Sat Feb 22 02:34:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30697C72; Sat, 22 Feb 2014 02:34:02 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01B7C18AE; Sat, 22 Feb 2014 02:34:01 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s1M2LNU7038741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 18:21:26 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5308099F.4090706@freebsd.org> Date: Sat, 22 Feb 2014 10:21:19 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wojciech A. Koszek" , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: BSD XXI Manifesto [agree] [intersting] References: <20140218072821.GF34282@FreeBSD.org> In-Reply-To: <20140218072821.GF34282@FreeBSD.org> 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.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 02:34:02 -0000 On 2/18/14, 3:28 PM, Wojciech A. Koszek wrote: > (cross-posted message: eventual discussion let's keep on hackers@) > > Hello, > > After being disappointed with the list of submitted FreeBSD ideas, I created > my own Machiavellist vision of XXI-century FreeBSD. I paste it below. If you > want to add something, it's here: > > https://wiki.freebsd.org/BSD_XXI_Manifesto > > GSOC students could use this as an inspiration for their projects. The idea > is to invite non-C, non-OS, non-kernel developers to help out with FreeBSD > stuff. > > ============ > > BSDXXI manifesto [nice stuff] removed for brevity I like all this.. I thought you meant XXI to mean the "FreeBSD's 21st year" but there is more than one year's worth of stuff there. I really suggest people seriously look at the list.. lots of really neat ideas. peole who are not necessarily C coders could do lots of this if we had a project to gather people under to do it. PCBSD people would be a core of interested people.. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 22 23:06:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61BB5396 for ; Sat, 22 Feb 2014 23:06:53 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1BE50165E for ; Sat, 22 Feb 2014 23:06:49 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id AFE591534D1; Sun, 23 Feb 2014 00:06:40 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq8LYojNCWPD; Sun, 23 Feb 2014 00:06:38 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 895BD153448; Sun, 23 Feb 2014 00:06:38 +0100 (CET) Message-ID: <53092D83.6050603@digiware.nl> Date: Sun, 23 Feb 2014 00:06:43 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Perry Hutchison , jordan.hubbard@gmail.com Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> In-Reply-To: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 23:06:53 -0000 On 16-2-2014 6:16, Perry Hutchison wrote: > Jordan Hubbard wrote: > >> Even variant symlinks (/bin -> /${ARCH}/bin), which can expand >> differently depending on the user context, have clearly >> understandable semantics - you know that the symlink is going >> to expand to exactly one file no matter what ARCH is set to. > > s/file/pathname/ > > Depending on what ARCH is set to, the expanision may or may not > point to any actual file (or directory, or ...) Yes, please can we get these .... Apollo Domain systems had those, and they were great. Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or SYSV to get the other stuff. Would indeed work great for things like /bin or even /usr/local/etc -> /${HOST}/usr/local/etc I was running a special patch version 2.2 at one time, that had variant replacement in the lookup-cache routines. But I never was able to figure out a handy way to get the info back into the kernel. So I gave up. One would need to get at the user environment of the process, and then parse and scrutinize the ENV every time you need to use a replacement. So probably libc is the place to put it, but then you get into trouble again when somebody uses the not standard libc... Also got a lot of flack from people suggesting it would create security problems.... (I beg to differ) But I would really like the timewarp back to 1985. --WjW