From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 6 00:13:07 2013 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 ESMTP id C64AE51C for ; Sun, 6 Oct 2013 00:13:07 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 903DE2CB5 for ; Sun, 6 Oct 2013 00:13:07 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id i1so5225471oag.6 for ; Sat, 05 Oct 2013 17:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=deoxIgGDR303kmMvkeg2nDP6gztl0fBxGp52wa+cv8k=; b=YcyE9bs0Ivhsyqw+oNJiRWyEh+ukx1DFRw91XKnlmFhYhp6N3SkgK2d1F50jTBrmQH F/4iMPPf6aKmmkBGJcfaerLNpnwM916fr6eTD7oEvpgepVV+Oi/6iNh+QsLpyyW9N0Su ZKmpM2qArK7xOVcQ678FZiExQLiggPJYwpISvR4HKZesz7u7loIlKrxLnFS+Kf1cJzGX BJ9WyxAtyJrFcbopMI0hlf4FKIW75NIaWb384Wv0EmMQjPyl4n/DoQQg7Cl6H+tH+KTY eTif6k0bV46ayy/ZQf1vnO0pHpEDr+yk+RH/DCDzSu/B6vEGaln73aNTP6i04a0b7EXq SX5g== MIME-Version: 1.0 X-Received: by 10.60.115.164 with SMTP id jp4mr34691409oeb.19.1381018386651; Sat, 05 Oct 2013 17:13:06 -0700 (PDT) Received: by 10.76.13.228 with HTTP; Sat, 5 Oct 2013 17:13:06 -0700 (PDT) In-Reply-To: <381FF194-928A-4483-B011-5A1B0A2EF93B@webweaving.org> References: <20130923094150.GM12210@mx.7he.at> <381FF194-928A-4483-B011-5A1B0A2EF93B@webweaving.org> Date: Sat, 5 Oct 2013 20:13:06 -0400 Message-ID: Subject: Re: VPS Project From: Outback Dingo To: Dirk-Willem van Gulik Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, "Klaus P. Ohrhallinger" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 00:13:07 -0000 On Mon, Sep 23, 2013 at 6:41 AM, Dirk-Willem van Gulik wrote: > > Op 23 sep. 2013, om 11:41 heeft "Klaus P. Ohrhallinger" het > volgende geschreven: > > > My virtualization project (http://www.7he.at/freebsd/vps/) has > > its project branch on svn.freebsd.org since a few months now. > > > > Since then there was not much progress due to lack of time. > > > > Now I am sitting on code updates that I can't commit myself. > > What is necessary to get commit right to /projects/vps ? > > > > Also it would be great if some FreeBSD developers could review > > parts of the code. So far, most feedback came from non-developers. > > can you maybe post a patch of the recent updates? > > Would be nice to see an update (most recent binary packages have drifted > too far to cleany apply); found it very usable for large number of > participating node-testing of network stacks. > > Dw. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 6 05:54:49 2013 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 ESMTP id 5636124F for ; Sun, 6 Oct 2013 05:54:49 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21EB72890 for ; Sun, 6 Oct 2013 05:54:48 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r965sm9t010101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 6 Oct 2013 00:54:48 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Sun, 6 Oct 2013 00:54:47 -0500 From: "Teske, Devin" To: Volodymyr Kostyrko Subject: Re: ZFS Boot Menu Thread-Topic: ZFS Boot Menu Thread-Index: AQHOvJHy7hpD2Osvt02Q7ZHQzImI/A== Date: Sun, 6 Oct 2013 05:54:46 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC3747C@LTCFISWMSGMB21.FNFIS.com> References: <13CA24D6AB415D428143D44749F57D720FC06B52@LTCFISWMSGMB21.FNFIS.com> <52497AB6.4070906@gmail.com> In-Reply-To: <52497AB6.4070906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <7466AC007A130948834074B8995B576F@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-06_01:2013-10-04,2013-10-06,1970-01-01 signatures=0 Cc: FreeBSD Hackers , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 05:54:49 -0000 On Sep 30, 2013, at 6:20 AM, Volodymyr Kostyrko wrote: > 29.09.2013 00:30, Teske, Devin wrote: >> Interested in feedback, but moreover I would like to see who is >> interested in tackling this with me? I can't do it alone... I at least >> need testers whom will provide feedback and edge-case testing. >=20 > Sign me in, I'm not fluent with forth but testing something new is always= fun. >=20 Cool; to start with, do you have a virtual appliance software like VMware or VirtualBox? Experience with generating ZFS pools in said software? I think that we may have something to test next month. Right now, we're working on the ability of bsdinstall(8) to provision "Boot= on ZFS" as a built-in functionality. This feature (when in; projected for 10.0-BETA1) will make testing the Forth enhancements easier (IMHO). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 6 07:30:51 2013 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 ESMTP id 2FEAE256; Sun, 6 Oct 2013 07:30:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 46B442C09; Sun, 6 Oct 2013 07:30:50 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e53so2611084eek.13 for ; Sun, 06 Oct 2013 00:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aEAivdcImJx+yXZI5NuiWTYkGe49ecX2SIFKvkhmty4=; b=WTTPkWUGjjMcV/bRX+SexY5dQnvUyNu9KLmpcu9rMwlLyv1kv97pWT1OLOOKpOdTn4 QPTY14AsZt8qAXxVvWshXTTQtJ2Gyn5rd/HXhwUKjup6CKx9GqtA+/18QCAI5iNs5Ky+ q/kiOiqIwauSh6osx3JUc4J9LJKaVsa/LoTZhGhJNCnRKLDn/TYmnDYL+yz8/XRlNSXR FktfHaKSiaRKpV/UT7teb3HA7lYhgQ6dMXjHwLFPvIVUIDp2BX344a1irStjc/udZomn OaiagxOFiZyoO8vJOnHU9KOguY26lf2soDNBuj0SYZ+Mylm6O70Z2TN2SBe81iQ3jDMG X9VA== X-Received: by 10.15.43.13 with SMTP id w13mr37255953eev.37.1381044647533; Sun, 06 Oct 2013 00:30:47 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([46.211.77.102]) by mx.google.com with ESMTPSA id v8sm48252297eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 00:30:45 -0700 (PDT) Sender: Alexander Motin Message-ID: <525111A2.1020106@FreeBSD.org> Date: Sun, 06 Oct 2013 10:30:42 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking References: <5224511D.4090503@FreeBSD.org> <20130906230236.GI43281@caravan.chchile.org> <522AC88D.4070005@FreeBSD.org> <201310021330.23251.jhb@freebsd.org> In-Reply-To: <201310021330.23251.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 07:30:51 -0000 On 02.10.2013 20:30, John Baldwin wrote: > On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: >> On 07.09.2013 02:02, Jeremie Le Hen wrote: >>> On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: >>>> On 06.09.2013 11:06, Jeremie Le Hen wrote: >>>>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labb� wrote: >>>>>> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin > wrote: >>>>>>> I've found and fixed possible double request completion, that could > cause >>>>>>> such symptoms if happened. Updated patch located as usual: >>>>>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch >>>>>>> >>>>> With this new one I cannot boot any more (I also updated the source >>>>> tree). This is a hand transcripted version: >>>>> >>>>> Trying to mount root from zfs:zroot/root []... >>>>> panic: Batch flag already set >>>>> cpuid = 1 >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper() >>>>> kdb_backtrace() >>>>> vpanic() >>>>> kassert_panic() >>>>> xpt_batch_start() >>>>> ata_interrupt() >>>>> softclock_call_cc() >>>>> softclock() >>>>> ithread_loop() >>>>> fork_exit() >>>>> fork_trampoline() >>>> >>>> Thank you for the report. I see my fault. It is probably specific to >>>> ata(4) driver only. I've workarounded that in new patch version, but >>>> probably that area needs some rethinking. >>>> >>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch >>> >>> I'm not sure you needed a confirmation, but it boots. Thanks :). >>> >>> I didn't quite understand the thread; is direct dispatch enabled for >>> amd64? ISTR you said only i386 but someone else posted the macro for >>> amd64. >> >> Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd64. > > FYI, I tested mfi with this patch set and mfid worked fine for handling g_up > directly: > > Index: dev/mfi/mfi_disk.c > =================================================================== > --- dev/mfi/mfi_disk.c (revision 257407) > +++ dev/mfi/mfi_disk.c (working copy) > @@ -162,6 +162,7 @@ > sc->ld_disk->d_unit = sc->ld_unit; > sc->ld_disk->d_sectorsize = secsize; > sc->ld_disk->d_mediasize = sectors * secsize; > + sc->ld_disk->d_flags = DISKFLAG_DIRECT_COMPLETION; > if (sc->ld_disk->d_mediasize >= (1 * 1024 * 1024)) { > sc->ld_disk->d_fwheads = 255; > sc->ld_disk->d_fwsectors = 63; > Thank you for the feedback. But looking on mfi driver sources I would say that it calls biodone() from mfi_disk_complete() from cm_complete() method, which is called while holding mfi_io_lock mutex. I guess that if on top of mfi device would be some GEOM class, supporting direct dispatch and sending new requests down on previous request completion (or retrying requests), that could cause recursive mfi_io_lock acquisition. That is exactly the cause why I've added this flag. May be it is a bit paranoid, but it is better to be safe then sorry. Another good reason to drop the lock before calling biodone() would be reducing the lock hold time. Otherwise it may just increase lock congestion there and destroy all benefits of the direct dispatch. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 6 19:26:15 2013 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 ESMTP id A5C559B9; Sun, 6 Oct 2013 19:26:15 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61C122B4F; Sun, 6 Oct 2013 19:26:15 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id ar20so14018835iec.32 for ; Sun, 06 Oct 2013 12:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=RzVULWIPIobqqS7Av5No7zALvJOMfptbl22Hz3Tes+w=; b=QS1NeAjjmUMFEQzn+cXlmNiVlja4JB2iDVYhTFO7foVUS//nxwBjziJoNEppOqdav0 OcgK4I7ORV5xR2z80bpqlac0VQgRQNJNq8RpQ9SkUvjHQBGSkPTvru2oBQyjMXhhjwsb SLEiHwBgV1LLRE9Tt0iJvNlOSJz/vkqP/LRywXUmf0ruVrO5uhZcnXuUX0JTjQWuiWIL 5F49YLho6lAZ9rShBsdUGJvgkjBExjhgW73IT+dIfPqKAqZgjw2ou1tDMFmFyhgy2D0F ZjrrpmJwN8aOjPnfyLo1i5yRFt57id2CnLCb6rZF5lzi8WvLHbermJ0TYgvmjupyf0qo A/wg== MIME-Version: 1.0 X-Received: by 10.50.45.100 with SMTP id l4mr14110990igm.60.1381087574830; Sun, 06 Oct 2013 12:26:14 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.64.27.105 with HTTP; Sun, 6 Oct 2013 12:26:14 -0700 (PDT) Date: Sun, 6 Oct 2013 21:26:14 +0200 X-Google-Sender-Auth: L1jQTvfLxuSh8bc30BKa8hSdZ_A Message-ID: Subject: Re: Call for FreeBSD 2013Q3 (July-September) Status Reports From: Gabor Pali To: hackers@freebsd.org, current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 19:26:15 -0000 Dear FreeBSD Community, This is another gentle reminder that the deadline for submissions for the third Quarterly Status Report is tomorrow! Please find the details quoted below. On Sun, Sep 29, 2013 at 12:22 PM, Gabor Pali wrote: > Dear FreeBSD Community, > > Please note that the next submission date for the July to September > Quarterly Status Reports is October 7th, 2013, bit more than a week > away. Please consult my previous message for the details: > > On Mon, Sep 9, 2013 at 12:04 AM, Gabor Pali wrote: >> They do not have to be very long -- basically they may be about >> anything that lets people know what is going on around the FreeBSD >> Project. Submission of reports is not restricted to committers: >> Anyone who is doing anything interesting and FreeBSD-related can (and >> therefore encouraged to) write one! >> >> The preferred and easiest submission method is to use the XML >> generator [1] with the result emailed as an attachment to us, that is, >> monthly@FreeBSD.org [2]. There is also an XML template [3] which can >> be filled out manually and attached if preferred. >> >> To enable compilation and publication of the Q3 report as soon as >> possible for the October 7th deadline, please be prompt with any >> report submissions you may have. >> >> We are looking forward to all of your 2013Q3 reports! >> >> Cheers, >> Gabor >> >> >> [1] http://www.freebsd.org/cgi/monthly.cgi >> [2] mailto:monthly@freebsd.org >> [3] http://www.freebsd.org/news/status/report-sample.xml From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 01:24:54 2013 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 ESMTP id 5E067EC3 for ; Mon, 7 Oct 2013 01:24:54 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B005A2A5E for ; Mon, 7 Oct 2013 01:24:53 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id d7so2319410bkh.40 for ; Sun, 06 Oct 2013 18:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=1hmudpPS4k2gCotqkNjJAFMfIzii//oZeK+0oR3gZuc=; b=iLnn51gKy8Wq82sNJOHg78bvVjSC1H5l7RhZuUlMY6Fp9qW3RaqeYYXgoLq6dsmf1E yuufhNlTCayuuG4EktyU7eo+o0Z51J4GKaq00y+ZrLkootJsu+a0taZ/NW4dL0954Q7u n49F8Jk515RF5qjGUjXchFOucX6Pv4KbEoKZFm0UeQJd7PEeKF7U8tZ2R2TpbgCuIRle 7oi6GExoXqis6TKgTpnWdBhLSlfCzIMs4Eb+VnOgCp+HiwAiEmqIf/pCEu96n3Qwd4Cm FvmOREcsHmkoXl1e3SKY+sCGDTyCCZmEOfS+WVhiRRxW7Uu2W1zL9IiwDRYEicP2YONj yMQw== X-Received: by 10.205.14.197 with SMTP id pr5mr24448564bkb.6.1381109089681; Sun, 06 Oct 2013 18:24:49 -0700 (PDT) Received: from rimwks1w7x64 ([2001:470:1f15:8e:187b:99b1:40f9:a00e]) by mx.google.com with ESMTPSA id nv4sm15476875bkb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 06 Oct 2013 18:24:47 -0700 (PDT) From: rozhuk.im@gmail.com To: Subject: amdtemp need help with testing Date: Mon, 7 Oct 2013 05:24:41 +0400 Message-ID: <52520d5f.c402cd0a.5f4e.ffffffa2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0206_01CEC31D.875A19E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7C+/7wCg7vkJ8uT3mTE7y1j9B7CQ== Content-Language: ru X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 01:24:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0206_01CEC31D.875A19E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I updated amdtemp and now I need your help with testing. Now the driver should support all AMD processors. For a family of 15h and 16h, not all sensors are available - for my system does not find drivers for ati SMBus, and other systems based on the AMD I have not. ------=_NextPart_000_0206_01CEC31D.875A19E0 Content-Type: text/plain; name="amdtemp.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="amdtemp.c" /*-=0A= * Copyright (c) 2008, 2009 Rui Paulo =0A= * Copyright (c) 2009 Norikatsu Shigemura =0A= * Copyright (c) 2009-2011 Jung-uk Kim =0A= * Copyright (c) 2013 Rozhuk Ivan =0A= * All rights reserved.=0A= *=0A= * Redistribution and use in source and binary forms, with or without=0A= * modification, are permitted provided that the following conditions=0A= * are met:=0A= * 1. Redistributions of source code must retain the above copyright=0A= * notice, this list of conditions and the following disclaimer.=0A= * 2. Redistributions in binary form must reproduce the above copyright=0A= * notice, this list of conditions and the following disclaimer in the=0A= * documentation and/or other materials provided with the = distribution.=0A= *=0A= * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR=0A= * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED=0A= * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE=0A= * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,=0A= * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES=0A= * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR=0A= * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)=0A= * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,=0A= * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING = IN=0A= * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE=0A= * POSSIBILITY OF SUCH DAMAGE.=0A= */=0A= =0A= /*=0A= * Driver for the AMD CPU on-die thermal sensors.=0A= * Initially based on the k8temp Linux driver.=0A= */=0A= =0A= #include =0A= __FBSDID("$FreeBSD$");=0A= =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= =0A= #include =0A= =0A= #if defined(__FreeBSD_version) && (__FreeBSD_version < 999999)=0A= /* XXX */=0A= extern uint32_t pci_cfgregread(int, int, int, int, int);=0A= #endif=0A= =0A= =0A= struct amdtemp_softc {=0A= device_t dev;=0A= struct mtx lock; /* Read/write lock for some registers. */=0A= uint32_t cpu_ncores;=0A= uint32_t flags;=0A= uint32_t tts_flags; /* Thermaltrip Status flags. */=0A= int32_t tts_temp_offset[4];=0A= int32_t rtc_temp_offset;=0A= int32_t tsi_temp_offset[8];=0A= struct sysctl_oid *sysctl_cpu[MAXCPU]; /* dev.cpu.X.temperature oids. */=0A= struct intr_config_hook sc_ich;=0A= };=0A= #define AMDTEMP_F_TTS 1 /* Thermaltrip Status. */=0A= #define AMDTEMP_F_RTC 2 /* Reported Temperature Control. */=0A= #define AMDTEMP_F_TSI 4 /* TSI via CPU registers. */=0A= #define AMDTEMP_F_SBTSI 8 /* TSI via SMBus. */=0A= =0A= #define AMDTEMP_TTS_F_CS_SWAP 0x01 /* ThermSenseCoreSel is inverted. */=0A= #define AMDTEMP_TTS_F_CT_10BIT 0x02 /* CurTmp is 10-bit wide. */=0A= #define AMDTEMP_TTS_F_OFF28 0x04 /* CurTmp starts at -28C. */=0A= =0A= =0A= #define AMDTEMP_LOCK(sc) mtx_lock(&(sc)->lock)=0A= #define AMDTEMP_UNLOCK(sc) mtx_unlock(&(sc)->lock)=0A= =0A= =0A= /* CPU Family/Model Register */=0A= #define AMD_REG_CPUID 0xfc=0A= =0A= /* =0A= * Thermaltrip Status Register=0A= * BIOS and Kernel Developer=E2=80=99s Guide for AMD NPT Family 0Fh = Processors=0A= * 32559 Rev. 3.16 November 2009=0A= */=0A= /* D18F3xE4 Thermtrip Status Register */=0A= #define AMD_REG_THERMTRIP_STAT 0xe4=0A= union reg_amd_thermtrip_status_desc {=0A= uint32_t u32;=0A= struct reg_amd_thermtrip_status_bits {=0A= uint32_t r0:1; /* 0 Reserved. */=0A= uint32_t Thermtp:1; /* 1 ro The processor has entered the THERMTRIP = state. */=0A= uint32_t ThermSenseCoreSel:1; /* 2 rw */=0A= uint32_t ThermtpSense0:1; /* 3 ro */=0A= uint32_t ThermtpSense1:1; /* 4 ro */=0A= uint32_t ThermtpEn:1; /* 5 ro The THERMTRIP state is supported by the = processor. */=0A= uint32_t ThermSenseSel:1; /* 6 rw */=0A= uint32_t r1:1; /* 7 Reserved. */=0A= uint32_t DiodeOffset:6; /* 13:8 ro Thermal diode offset is used to = correct the measurement made by an external temperature sensor. */=0A= uint32_t CurTmp:10; /* 23:14 ro This field returns the current value = of the internal thermal sensor. */=0A= uint32_t TjOffset:5; /* 28:24 ro This field is the offset from CurTmp = used to normalize to Tcontrol. */=0A= uint32_t r2:2; /* 30:29 Reserved. */=0A= uint32_t SwThermtp:1; /* 31 rw */=0A= } __packed bits;=0A= };=0A= =0A= =0A= /* DRAM Configuration High Register */=0A= #define AMD_REG_DRAM_CONF_HIGH 0x94 /* Function 2 */=0A= #define AMD_REG_DRAM_MODE_DDR3 0x0100=0A= =0A= /* D18F3xA4 Reported Temperature Control Register */=0A= #define AMD_REG_REPTMP_CTRL 0xa4=0A= union reg_amd_rep_tmp_ctrl_desc {=0A= uint32_t u32;=0A= struct reg_amd_rep_tmp_ctrl_bits {=0A= uint32_t PerStepTimeUp:5; /* 4:0 rw per 1/8th step time up. */=0A= uint32_t TmpMaxDiffUp:2;/* 6:5 rw temperature maximum difference up. */=0A= uint32_t TmpSlewDnEn:1; /* 7 rw temperature slew downward enable. */=0A= uint32_t PerStepTimeDn:5;/* 12:8 rw per 1/8th step time down. */=0A= uint32_t r0:3; /* 15:13 Reserved. */=0A= uint32_t CurTmpTjSel:2; /* 17:16 rw Current temperature select. */=0A= uint32_t r1:3; /* 20:18 Reserved. */=0A= uint32_t CurTmp:11; /* 31:21 ro/rw current temperature. */=0A= } __packed bits;=0A= };=0A= /* CurTmpTjSel valid family 10h, 15h, 16h processors. */=0A= =0A= =0A= /* SB-TSI */=0A= #define AMD_REG_SBI_CTRL 0x1e4 /* SBI Control */=0A= union reg_amd_sbi_ctrl_desc {=0A= uint32_t u32;=0A= struct reg_amd_sbi_ctrl_bits {=0A= uint32_t r0:1; /* 0 Reserved. */=0A= uint32_t SbRmiDis:1; /* 1 ro SMBus-based sideband remote management = interface disable. */=0A= uint32_t r1:1; /* 2 Reserved. */=0A= uint32_t SbTsiDis:1; /* 3 ro SMBus-based sideband temperature sensor = interface disable. */=0A= uint32_t SbiAddr:3; /* 6:4 rw SMBus-based sideband interface address. = */=0A= uint32_t r2:1; /* 7 Reserved. */=0A= uint32_t LvtOffset:4; /* 11:8 rw local vector table offset. */=0A= uint32_t r3:19; /* 30:12 Reserved. */=0A= uint32_t SbiRegWrDn:1; /* 31 ro SBI register write complete. */=0A= } __packed bits;=0A= };=0A= /*=0A= * AMD Family 10h Processor BKDG: SbRmiDis (bit offset: 1) + SbTsiDis = (bit offset: 3)=0A= * AMD Family 11h Processor BKDG: SbTsiDis (bit offset: 1)=0A= * AMD Family 12h Processor BKDG: SbTsiDis (bit offset: 1)=0A= * BKDG for AMD Family 14h Models 00h-0Fh Processors: SbTsiDis (bit = offset: 1)=0A= * BKDG for AMD Family 15h Models 00h-0Fh Processors: SbRmiDis, no TSI=0A= * BKDG for AMD Family 16h Models 00h-0Fh Processors: ??? 48751 Rev 3.00 = - May 30, 2013=0A= */=0A= #define AMD_REG_SBI_ADDR 0x1e8 /* SBI Address */=0A= #define AMD_REG_SBI_ADDR_MASK 0x07=0A= #define AMD_REG_SBI_DATA 0x1ec /* SBI Data */=0A= #define AMD_SBI_WRITE_TIMEOUT 100 /* XXX should be increased? */=0A= =0A= /* SB-TSI registers. */=0A= #define SB_TSI_REG_CPU_TEMP_HB 0x01 /* CPU Temperature High Byte = Register. */=0A= #define SB_TSI_REG_STATUS 0x02 /* SB-TSI Status Register. */=0A= #define SB_TSI_REG_CFG 0x03 /* SB-TSI Configuration Register. */=0A= #define SB_TSI_REG_UPD_RATE 0x04 /* Update Rate Register. */=0A= #define SB_TSI_REG_HIGH_TEMP_THB 0x07 /* High Temperature Threshold High = Byte Register. */=0A= #define SB_TSI_REG_LOW_TEMP_THB 0x08 /* Low Temperature Threshold High = Byte Register.*/=0A= #define SB_TSI_REG_CFG2 0x09 /* SB-TSI Configuration Register. */=0A= #define SB_TSI_REG_CPU_TEMP_LB 0x10 /* CPU Temperature Low Byte = Register. */=0A= #define SB_TSI_REG_CPU_TEMP_OFF_HB 0x11 /* CPU Temperature Offset High = Byte Register. */=0A= #define SB_TSI_REG_CPU_TEMP_OFF_LB 0x12 /* CPU Temperature Offset Low = Byte Register. */=0A= #define SB_TSI_REG_HIGH_TEMP_TLB 0x13 /* High Temperature Threshold Low = Byte Register. */=0A= #define SB_TSI_REG_LOW_TEMP_TLB 0x14 /* Low Temperature Threshold Low = Byte Register. */=0A= #define SB_TSI_REG_TIMEOUT_CFG 0x22 /* Timeout Configuration Register. = */=0A= #define SB_TSI_REG_ALERT_THRESHOLD 0x32 /* Alert Threshold Register. */=0A= #define SB_TSI_REG_ALERT_CFG 0xbf /* Alert Configuration Register. */=0A= #define SB_TSI_REG_MANUFACTURE_ID 0xfe /* Manufacture ID Register. */=0A= #define SB_TSI_REG_REVISION 0xff /* SB-TSI Revision Register. */=0A= =0A= =0A= =0A= #define AMDTEMP_ZERO_C_TO_K 2732=0A= =0A= =0A= #define ARG2_GET_REG(arg) ((arg) & 0xffff)=0A= #define ARG2_GET_A1(arg) (((arg) >> 16) & 0xff)=0A= #define ARG2_GET_A2(arg) (((arg) >> 24) & 0xff)=0A= #define MAKE_ARG2(reg, a1, a2) \=0A= (((reg) & 0xff) | (((a1) & 0xff) << 16) | (((a2) & 0xff) << 24))=0A= =0A= struct amdtemp_sysctl_reg {=0A= uint16_t reg;=0A= uint8_t a1;=0A= uint8_t a2;=0A= uint32_t flags;=0A= char *fmt;=0A= int (*oid_handler)(SYSCTL_HANDLER_ARGS);=0A= char *name;=0A= char *descr;=0A= };=0A= =0A= static void amdtemp_sysctl_reg_add(struct amdtemp_softc *sc,=0A= struct sysctl_oid_list *child, struct amdtemp_sysctl_reg *regs);=0A= static void amdtemp_sysctl_reg_add2(struct amdtemp_softc *sc,=0A= struct sysctl_oid_list *child, struct amdtemp_sysctl_reg *regs,=0A= uint32_t a2);=0A= static int amdtemp_sysctl_reg_bits(SYSCTL_HANDLER_ARGS);=0A= =0A= static uint32_t amdtemp_tts_get_temp(struct amdtemp_softc *sc, uint32_t = reg,=0A= uint8_t core, uint8_t sense);=0A= static int amdtemp_tts_temp_reg_sysctl(SYSCTL_HANDLER_ARGS);=0A= =0A= static int amdtemp_rtc_temp_sysctl(SYSCTL_HANDLER_ARGS);=0A= =0A= static void amdtemp_sbi_set_addr(struct amdtemp_softc *sc, uint32_t = sbi_addr);=0A= static uint32_t amdtemp_sbi_read(struct amdtemp_softc *sc, uint32_t = sbi_addr,=0A= uint32_t reg_addr);=0A= static int amdtemp_sbi_write(struct amdtemp_softc *sc, uint32_t sbi_addr,=0A= uint32_t reg_addr, uint8_t data);=0A= static int amdtemp_tsi_reg_sysctl(SYSCTL_HANDLER_ARGS);=0A= static int amdtemp_tsi_temp_reg_sysctl(SYSCTL_HANDLER_ARGS);=0A= =0A= =0A= /* D18F3xE4 Thermtrip Status Register */=0A= static struct amdtemp_sysctl_reg amdtemp_thermtrip_status_reg_bits[] =3D = {=0A= { AMD_REG_THERMTRIP_STAT, 24, 5, (CTLFLAG_RD | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "TjOffset", "This field is the offset from = CurTmp used to normalize to Tcontrol." },=0A= { AMD_REG_THERMTRIP_STAT, 8, 6, (CTLFLAG_RD | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "DiodeOffset", "Thermal diode offset is used to = correct the measurement made by an external temperature sensor." },=0A= { AMD_REG_THERMTRIP_STAT, 5, 1, (CTLFLAG_RD | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "ThermtpEn", "The THERMTRIP state is supported = by the processor." },=0A= { AMD_REG_THERMTRIP_STAT, 1, 1, (CTLFLAG_RD | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "Thermtrip", "The processor has entered the = THERMTRIP state." },=0A= =0A= { 0, 0, 0, 0, NULL, NULL, NULL, NULL }=0A= };=0A= =0A= /* D18F3xA4 Reported Temperature Control Register */=0A= static struct amdtemp_sysctl_reg amdtemp_reptmp_reg_bits[] =3D {=0A= { AMD_REG_REPTMP_CTRL, 21,11, (CTLFLAG_RD | CTLTYPE_INT), "IK", = amdtemp_rtc_temp_sysctl, "CurTmp", "Provides the current control = temperature, Tctl, after the slew-rate controls have been applied." },=0A= { AMD_REG_REPTMP_CTRL, 16, 2, (CTLFLAG_RW | CTLTYPE_INT), "IK", = amdtemp_rtc_temp_sysctl, "CurTmpTjSel", "Specifies a value used to = create Tctl." },=0A= { AMD_REG_REPTMP_CTRL, 7, 1, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "TmpSlewDnEn", "Temperature slew downward = enable." },=0A= { AMD_REG_REPTMP_CTRL, 5, 2, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "TmpMaxDiffUp", "Specifies the maximum = difference, (Tctlm - Tctl), when Tctl immediatly updates to Tctlm." },=0A= { AMD_REG_REPTMP_CTRL, 8, 5, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "PerStepTimeDn", "Specifies the time that Tctlm = must remain below Tctl before applying a 0.125 downward step." },=0A= { AMD_REG_REPTMP_CTRL, 0, 5, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_sysctl_reg_bits, "PerStepTimeUp", "Specifies the time that Tctlm = must remain above Tctl before applying a 0.125 upward step." },=0A= =0A= { 0, 0, 0, 0, NULL, NULL, NULL, NULL }=0A= };=0A= =0A= /* SB-TSI registers. */=0A= static struct amdtemp_sysctl_reg amdtemp_tsi_regs[] =3D {=0A= { SB_TSI_REG_CPU_TEMP_LB, SB_TSI_REG_CPU_TEMP_HB, 0, (CTLFLAG_RD | = CTLTYPE_INT), "IK", amdtemp_tsi_temp_reg_sysctl, "cpu_temperature", "CPU = Temperature" },=0A= { SB_TSI_REG_HIGH_TEMP_TLB, SB_TSI_REG_HIGH_TEMP_THB, 0, (CTLFLAG_RD | = CTLTYPE_INT), "IK", amdtemp_tsi_temp_reg_sysctl, = "high_temperature_threshold", "High Temperature Threshold" },=0A= { SB_TSI_REG_LOW_TEMP_TLB, SB_TSI_REG_LOW_TEMP_THB, 0, (CTLFLAG_RD | = CTLTYPE_INT), "IK", amdtemp_tsi_temp_reg_sysctl, = "low_temperature_threshold", "Low Temperature Threshold" },=0A= =0A= { SB_TSI_REG_CPU_TEMP_OFF_HB, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "cpu_temperature_offset_hi", "CPU Temperature = Offset High Byte" },=0A= { SB_TSI_REG_CPU_TEMP_OFF_LB, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "cpu_temperature_offset_lo", "CPU Temperature = Offset Low Byte" },=0A= =0A= { SB_TSI_REG_STATUS, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "status", "SB-TSI Status" },=0A= { SB_TSI_REG_CFG, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "cfg3", "SB-TSI Configuration Register 0x03" },=0A= { SB_TSI_REG_CFG2, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "cfg9", "SB-TSI Configuration Register 0x09" },=0A= { SB_TSI_REG_UPD_RATE, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "upd_rate", "Update Rate" },=0A= { SB_TSI_REG_TIMEOUT_CFG, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "timeout_cfg", "Timeout Configuration" },=0A= { SB_TSI_REG_ALERT_THRESHOLD, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "alert_threshold", "Alert Threshold" },=0A= { SB_TSI_REG_ALERT_CFG, 0, 0, (CTLFLAG_RW | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "alert_cfg", "Alert Configuration" },=0A= { SB_TSI_REG_MANUFACTURE_ID, 0, 0, (CTLFLAG_RD | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "manufacture_id", "Manufacture ID" },=0A= { SB_TSI_REG_REVISION, 0, 0, (CTLFLAG_RD | CTLTYPE_UINT), "IU", = amdtemp_tsi_reg_sysctl, "revision", "SB-TSI Revision" },=0A= =0A= { 0, 0, 0, 0, NULL, NULL, NULL, NULL }=0A= };=0A= =0A= =0A= /*=0A= * Device methods.=0A= */=0A= static void amdtemp_identify(driver_t *driver, device_t parent);=0A= static int amdtemp_probe(device_t dev);=0A= static int amdtemp_attach(device_t dev);=0A= static int amdtemp_detach(device_t dev);=0A= static void amdtemp_intrhook(void *arg);=0A= =0A= =0A= static device_method_t amdtemp_methods[] =3D {=0A= /* Device interface */=0A= DEVMETHOD(device_identify, amdtemp_identify),=0A= DEVMETHOD(device_probe, amdtemp_probe),=0A= DEVMETHOD(device_attach, amdtemp_attach),=0A= DEVMETHOD(device_detach, amdtemp_detach),=0A= =0A= DEVMETHOD_END=0A= };=0A= =0A= static driver_t amdtemp_driver =3D {=0A= "amdtemp",=0A= amdtemp_methods,=0A= sizeof(struct amdtemp_softc),=0A= };=0A= static devclass_t amdtemp_devclass;=0A= DRIVER_MODULE(amdtemp, hostb, amdtemp_driver, amdtemp_devclass, NULL, = NULL);=0A= MODULE_VERSION(amdtemp, 1);=0A= =0A= =0A= =0A= static void=0A= amdtemp_identify(driver_t *driver, device_t parent) {=0A= device_t child;=0A= uint32_t cpuid, model;=0A= =0A= /* Make sure we're not being doubly invoked. */=0A= if (device_find_child(parent, "amdtemp", -1) !=3D NULL)=0A= return;=0A= /* AMD processors only. */=0A= if (CPU_VENDOR_AMD !=3D pci_get_vendor(parent))=0A= return;=0A= /* Is processor supported? */=0A= cpuid =3D pci_read_config(parent, AMD_REG_CPUID, 4);=0A= switch (CPUID_TO_FAMILY(cpuid)) {=0A= case 0x0f:=0A= model =3D CPUID_TO_MODEL(cpuid);=0A= if ((model =3D=3D 0x04 && (cpuid & CPUID_STEPPING) =3D=3D 0) ||=0A= (model =3D=3D 0x05 && (cpuid & CPUID_STEPPING) <=3D 1))=0A= return;=0A= break;=0A= case 0x10:=0A= case 0x11:=0A= case 0x12:=0A= case 0x14:=0A= case 0x15:=0A= case 0x16:=0A= break;=0A= default:=0A= return;=0A= }=0A= /* Ok! */=0A= child =3D device_add_child(parent, "amdtemp", -1);=0A= if (child =3D=3D NULL)=0A= device_printf(parent, "add amdtemp child failed\n");=0A= }=0A= =0A= static int=0A= amdtemp_probe(device_t dev) {=0A= =0A= if (resource_disabled("amdtemp", 0))=0A= return (ENXIO);=0A= =0A= device_set_desc(dev, "AMD CPU On-Die Thermal Sensors");=0A= =0A= return (BUS_PROBE_GENERIC);=0A= }=0A= =0A= static int=0A= amdtemp_attach(device_t dev) {=0A= struct amdtemp_softc *sc =3D device_get_softc(dev);=0A= uint32_t i, cpuid, model;=0A= union reg_amd_sbi_ctrl_desc reg_ctrl;=0A= struct sysctl_ctx_list *ctx =3D device_get_sysctl_ctx(dev);=0A= struct sysctl_oid_list *child =3D = SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), *list;=0A= struct sysctl_oid *node, *sub_node;=0A= char str[32];=0A= int erratum319 =3D 0;=0A= u_int regs[4], bid;=0A= =0A= sc->dev =3D dev;=0A= /* Find number of cores per package. */=0A= sc->cpu_ncores =3D (((amd_feature2 & AMDID2_CMP) !=3D 0) ?=0A= ((cpu_procinfo2 & AMDID_CMP_CORES) + 1) : 1);=0A= if (sc->cpu_ncores > MAXCPU)=0A= return (ENXIO);=0A= mtx_init(&sc->lock, device_get_nameunit(dev), "amdtemp", MTX_DEF);=0A= =0A= cpuid =3D pci_read_config(dev, AMD_REG_CPUID, 4);=0A= model =3D CPUID_TO_MODEL(cpuid);=0A= switch (CPUID_TO_FAMILY(cpuid)) {=0A= case 0x0f:=0A= /*=0A= * Thermaltrip Status Register=0A= *=0A= * - ThermSenseCoreSel=0A= *=0A= * Revision F & G: 0 - Core1, 1 - Core0=0A= * Other: 0 - Core0, 1 - Core1=0A= *=0A= * - CurTmp=0A= *=0A= * Revision G: bits 23-14=0A= * Other: bits 23-16=0A= *=0A= * XXX According to the BKDG, CurTmp, ThermSenseSel and=0A= * ThermSenseCoreSel bits were introduced in Revision F=0A= * but CurTmp seems working fine as early as Revision C.=0A= * However, it is not clear whether ThermSenseSel and/or=0A= * ThermSenseCoreSel work in undocumented cases as well.=0A= * In fact, the Linux driver suggests it may not work but=0A= * we just assume it does until we find otherwise.=0A= *=0A= * XXX According to Linux, CurTmp starts at -28C on=0A= * Socket AM2 Revision G processors, which is not=0A= * documented anywhere.=0A= * XXX check TjOffset and DiodeOffset for -49C / -28C=0A= */=0A= if ((model =3D=3D 0x04 && (cpuid & CPUID_STEPPING) =3D=3D 0) ||=0A= (model =3D=3D 0x05 && (cpuid & CPUID_STEPPING) <=3D 1))=0A= break; /* No ThermalTrip. */=0A= sc->flags |=3D AMDTEMP_F_TTS;=0A= if (model >=3D 0x40)=0A= sc->tts_flags |=3D AMDTEMP_TTS_F_CS_SWAP;=0A= if (model >=3D 0x60 && model !=3D 0xc1) {=0A= do_cpuid(0x80000001, regs);=0A= bid =3D (regs[1] >> 9) & 0x1f;=0A= switch (model) {=0A= case 0x68: /* Socket S1g1 */=0A= case 0x6c:=0A= case 0x7c:=0A= break;=0A= case 0x6b: /* Socket AM2 and ASB1 (2 cores) */=0A= if (bid !=3D 0x0b &&=0A= bid !=3D 0x0c)=0A= sc->tts_flags |=3D AMDTEMP_TTS_F_OFF28;=0A= break;=0A= case 0x6f: /* Socket AM2 and ASB1 (1 core) */=0A= case 0x7f:=0A= if (bid !=3D 0x07 &&=0A= bid !=3D 0x09 &&=0A= bid !=3D 0x0c)=0A= sc->tts_flags |=3D AMDTEMP_TTS_F_OFF28;=0A= break;=0A= default:=0A= sc->tts_flags |=3D AMDTEMP_TTS_F_OFF28;=0A= }=0A= sc->tts_flags |=3D AMDTEMP_TTS_F_CT_10BIT;=0A= }=0A= break;=0A= case 0x10:=0A= sc->flags |=3D AMDTEMP_F_RTC;=0A= reg_ctrl.u32 =3D pci_read_config(dev, AMD_REG_SBI_CTRL, 4);=0A= if (0 =3D=3D reg_ctrl.bits.SbTsiDis)=0A= sc->flags |=3D AMDTEMP_F_TSI;=0A= /*=0A= * Erratum 319 Inaccurate Temperature Measurement=0A= * http://support.amd.com/us/Processor_TechDocs/41322.pdf=0A= */=0A= do_cpuid(0x80000001, regs);=0A= switch ((regs[1] >> 28) & 0xf) {=0A= case 0: /* Socket F */=0A= erratum319 =3D 1;=0A= break;=0A= case 1: /* Socket AM2+ or AM3 */=0A= if ((pci_cfgregread(pci_get_bus(dev), pci_get_slot(dev), 2,=0A= AMD_REG_DRAM_CONF_HIGH, 2) & AMD_REG_DRAM_MODE_DDR3) !=3D 0 ||=0A= model > 0x04 ||=0A= (model =3D=3D 0x04 && (cpuid & CPUID_STEPPING) >=3D 3))=0A= break;=0A= /* XXX 00100F42h (RB-C2) exists in both formats. */=0A= erratum319 =3D 1;=0A= break;=0A= }=0A= break;=0A= case 0x11:=0A= case 0x12:=0A= case 0x14:=0A= sc->flags |=3D AMDTEMP_F_RTC;=0A= reg_ctrl.u32 =3D pci_read_config(dev, AMD_REG_SBI_CTRL, 4);=0A= if (0 =3D=3D reg_ctrl.bits.SbRmiDis) /* =3D SbTsiDis */=0A= sc->flags |=3D AMDTEMP_F_TSI;=0A= break;=0A= case 0x15:=0A= case 0x16:=0A= default:=0A= sc->flags |=3D AMDTEMP_F_RTC;=0A= /* XXX TODO: read TSI via SMBus. */=0A= break;=0A= }=0A= =0A= if (0 !=3D (sc->flags & AMDTEMP_F_TTS)) { /* Thermaltrip Status */=0A= node =3D SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "tts",=0A= CTLFLAG_RD, NULL, "Thermaltrip Status");=0A= list =3D SYSCTL_CHILDREN(node);=0A= amdtemp_sysctl_reg_add(sc, list, amdtemp_thermtrip_status_reg_bits);=0A= for (i =3D 0; i < sc->cpu_ncores && i < 2; i ++) {=0A= snprintf(str, sizeof(str), "core%i", i);=0A= sub_node =3D SYSCTL_ADD_NODE(ctx, list, OID_AUTO, str,=0A= CTLFLAG_RD, NULL, "CPU core sensors");=0A= SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(sub_node), OID_AUTO,=0A= "sensor0", (CTLTYPE_INT | CTLFLAG_RD), sc,=0A= MAKE_ARG2(AMD_REG_THERMTRIP_STAT, i, 0),=0A= amdtemp_tts_temp_reg_sysctl, "IK", "Sensor 0 temperature");=0A= SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(sub_node), OID_AUTO,=0A= "sensor1", (CTLTYPE_INT | CTLFLAG_RD), sc,=0A= MAKE_ARG2(AMD_REG_THERMTRIP_STAT, i, 1),=0A= amdtemp_tts_temp_reg_sysctl, "IK", "Sensor 1 temperature");=0A= SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(sub_node), OID_AUTO,=0A= "sensor0_offset", CTLFLAG_RW,=0A= &sc->tts_temp_offset[((i << 1) | 0)], 0,=0A= "Temperature sensor offset");=0A= SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(sub_node), OID_AUTO,=0A= "sensor1_offset", CTLFLAG_RW,=0A= &sc->tts_temp_offset[((i << 1) | 1)], 0,=0A= "Temperature sensor offset");=0A= }=0A= }=0A= if (0 !=3D (sc->flags & AMDTEMP_F_RTC)) { /* Reported Temperature = Control */=0A= node =3D SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "rtc",=0A= CTLFLAG_RD, NULL, "Reported Temperature Control");=0A= list =3D SYSCTL_CHILDREN(node);=0A= amdtemp_sysctl_reg_add(sc, list, amdtemp_reptmp_reg_bits);=0A= SYSCTL_ADD_INT(ctx, list, OID_AUTO, "sensor_offset", CTLFLAG_RW,=0A= &sc->rtc_temp_offset, 0, "Temperature sensor offset");=0A= }=0A= if (0 !=3D (sc->flags & AMDTEMP_F_TSI)) { /* Temperature Sensor = Interface */=0A= node =3D SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "tsi",=0A= CTLFLAG_RD, NULL, "Temperature Sensor Interface");=0A= list =3D SYSCTL_CHILDREN(node);=0A= for (i =3D 0; i < 8; i ++) {=0A= if (0 =3D=3D amdtemp_sbi_read(sc, i, SB_TSI_REG_REVISION))=0A= continue;=0A= snprintf(str, sizeof(str), "sensor%i", i);=0A= sub_node =3D SYSCTL_ADD_NODE(ctx, list, OID_AUTO, str,=0A= CTLFLAG_RD, NULL, "TSI sensor");=0A= amdtemp_sysctl_reg_add2(sc, SYSCTL_CHILDREN(sub_node),=0A= amdtemp_tsi_regs, i);=0A= SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(sub_node), OID_AUTO,=0A= "sensor_offset", CTLFLAG_RW, &sc->tsi_temp_offset[i], 0,=0A= "Temperature sensor offset");=0A= }=0A= }=0A= =0A= if (bootverbose) {=0A= if (0 !=3D (sc->flags & AMDTEMP_F_TTS))=0A= device_printf(dev, "Found: Thermaltrip Status.\n");=0A= if (0 !=3D (sc->flags & AMDTEMP_F_RTC))=0A= device_printf(dev, "Found: Reported Temperature Control.\n");=0A= if (0 !=3D (sc->flags & AMDTEMP_F_TSI))=0A= device_printf(dev, "Found: Temperature Sensor Interface via CPU = registers.\n");=0A= }=0A= if (erratum319)=0A= device_printf(dev,=0A= "Erratum 319: temperature measurement may be inaccurate\n");=0A= /*=0A= * Try to create dev.cpu sysctl entries and setup intrhook function.=0A= * This is needed because the cpu driver may be loaded late on boot,=0A= * after us.=0A= */=0A= amdtemp_intrhook(dev);=0A= if (NULL =3D=3D sc->sysctl_cpu[i]) {=0A= sc->sc_ich.ich_func =3D amdtemp_intrhook;=0A= sc->sc_ich.ich_arg =3D sc;=0A= if (config_intrhook_establish(&sc->sc_ich) !=3D 0) {=0A= amdtemp_detach(dev);=0A= device_printf(dev, "config_intrhook_establish failed!\n");=0A= return (ENXIO);=0A= }=0A= }=0A= return (0);=0A= }=0A= =0A= int=0A= amdtemp_detach(device_t dev) {=0A= struct amdtemp_softc *sc =3D device_get_softc(dev);=0A= uint32_t i;=0A= =0A= for (i =3D 0; i < sc->cpu_ncores; i++)=0A= if (sc->sysctl_cpu[i] !=3D NULL)=0A= sysctl_remove_oid(sc->sysctl_cpu[i], 1, 0);=0A= /* NewBus removes the dev.amdtemp.N tree by itself. */=0A= if (sc->sc_ich.ich_arg !=3D NULL) {=0A= sc->sc_ich.ich_arg =3D NULL;=0A= config_intrhook_disestablish(&sc->sc_ich);=0A= }=0A= mtx_destroy(&sc->lock);=0A= =0A= return (0);=0A= }=0A= =0A= void=0A= amdtemp_intrhook(void *arg) {=0A= struct amdtemp_softc *sc =3D arg;=0A= struct sysctl_ctx_list *sysctlctx;=0A= device_t dev =3D sc->dev, acpi, cpu, nexus;=0A= int (*sysctl_handler)(SYSCTL_HANDLER_ARGS);=0A= intptr_t sysctl_arg2;=0A= uint32_t i, unit_base;=0A= =0A= if (sc->sc_ich.ich_arg !=3D NULL) {=0A= sc->sc_ich.ich_arg =3D NULL;=0A= config_intrhook_disestablish(&sc->sc_ich);=0A= }=0A= =0A= /* dev.cpu.N.temperature. */=0A= nexus =3D device_find_child(root_bus, "nexus", 0);=0A= acpi =3D device_find_child(nexus, "acpi", 0);=0A= unit_base =3D (device_get_unit(dev) * sc->cpu_ncores); /* XXX: = cpu_ncores not constant for different CPUs... */=0A= =0A= for (i =3D 0; i < sc->cpu_ncores; i ++) {=0A= if (sc->sysctl_cpu[i] !=3D NULL)=0A= continue;=0A= cpu =3D device_find_child(acpi, "cpu", (unit_base + i));=0A= if (cpu =3D=3D NULL)=0A= continue;=0A= sysctl_handler =3D NULL;=0A= if (0 !=3D (sc->flags & AMDTEMP_F_TSI)) { /* Temperature Sensor = Interface */=0A= if (0 =3D=3D amdtemp_sbi_read(sc, i, SB_TSI_REG_REVISION))=0A= continue;=0A= sysctl_handler =3D amdtemp_tsi_temp_reg_sysctl;=0A= sysctl_arg2 =3D MAKE_ARG2(SB_TSI_REG_CPU_TEMP_LB,=0A= SB_TSI_REG_CPU_TEMP_HB, i);=0A= } else if (0 !=3D (sc->flags & AMDTEMP_F_RTC)) { /* Reported = Temperature Control */=0A= sysctl_handler =3D amdtemp_rtc_temp_sysctl;=0A= sysctl_arg2 =3D MAKE_ARG2(AMD_REG_REPTMP_CTRL, 21, 11);=0A= } else if (0 !=3D (sc->flags & AMDTEMP_F_TTS)) { /* Thermaltrip Status = */=0A= sysctl_handler =3D amdtemp_tts_temp_reg_sysctl;=0A= sysctl_arg2 =3D MAKE_ARG2(AMD_REG_THERMTRIP_STAT, i, 0xff);=0A= }=0A= if (NULL =3D=3D sysctl_handler)=0A= continue;=0A= sysctlctx =3D device_get_sysctl_ctx(cpu);=0A= sc->sysctl_cpu[i] =3D SYSCTL_ADD_PROC(sysctlctx,=0A= SYSCTL_CHILDREN(device_get_sysctl_tree(cpu)), OID_AUTO,=0A= "temperature", (CTLTYPE_INT | CTLFLAG_RD), sc, sysctl_arg2,=0A= sysctl_handler, "IK", "Current temparature");=0A= }=0A= }=0A= =0A= =0A= /* Sysctl staff. */=0A= static void=0A= amdtemp_sysctl_reg_add(struct amdtemp_softc *sc, struct sysctl_oid_list = *child,=0A= struct amdtemp_sysctl_reg *regs) {=0A= struct sysctl_ctx_list *ctx =3D device_get_sysctl_ctx(sc->dev);=0A= uint32_t i;=0A= =0A= for (i =3D 0; NULL !=3D regs[i].oid_handler; i ++) {=0A= SYSCTL_ADD_PROC(ctx, child, OID_AUTO, regs[i].name,=0A= regs[i].flags, sc,=0A= MAKE_ARG2(regs[i].reg, regs[i].a1, regs[i].a2),=0A= regs[i].oid_handler, regs[i].fmt, regs[i].descr);=0A= }=0A= }=0A= =0A= static void=0A= amdtemp_sysctl_reg_add2(struct amdtemp_softc *sc, struct sysctl_oid_list = *child,=0A= struct amdtemp_sysctl_reg *regs, uint32_t a2) {=0A= struct sysctl_ctx_list *ctx =3D device_get_sysctl_ctx(sc->dev);=0A= uint32_t i;=0A= =0A= for (i =3D 0; NULL !=3D regs[i].oid_handler; i ++) {=0A= SYSCTL_ADD_PROC(ctx, child, OID_AUTO, regs[i].name,=0A= regs[i].flags, sc,=0A= MAKE_ARG2(regs[i].reg, regs[i].a1, a2),=0A= regs[i].oid_handler, regs[i].fmt, regs[i].descr);=0A= }=0A= }=0A= =0A= static int=0A= amdtemp_sysctl_reg_bits(SYSCTL_HANDLER_ARGS) {=0A= struct amdtemp_softc *sc =3D arg1;=0A= uint32_t i, reg_data, reg_num, bits_off, bits_len, bits_mask =3D 0;=0A= unsigned val;=0A= int error;=0A= =0A= reg_num =3D ARG2_GET_REG(arg2);=0A= bits_off =3D ARG2_GET_A1(arg2);=0A= bits_len =3D ARG2_GET_A2(arg2);=0A= reg_data =3D pci_read_config(sc->dev, reg_num, 4);=0A= =0A= for(i =3D 0; i < bits_len; i ++)=0A= bits_mask |=3D ((uint32_t)1 << i);=0A= =0A= val =3D ((reg_data >> bits_off) & bits_mask);=0A= error =3D sysctl_handle_int(oidp, &val, 0, req);=0A= if (0 !=3D error || NULL =3D=3D req->newptr || val =3D=3D reg_data)=0A= return (error);=0A= reg_data &=3D ~(bits_mask << bits_off); // clear all bits at offset=0A= reg_data |=3D ((val & bits_mask) << bits_off); // set value bits=0A= pci_write_config(sc->dev, reg_num, reg_data, 4);=0A= =0A= return (0);=0A= }=0A= =0A= =0A= /* Thermaltrip Status Register */=0A= static uint32_t=0A= amdtemp_tts_get_temp(struct amdtemp_softc *sc, uint32_t reg, uint8_t = core,=0A= uint8_t sense) {=0A= union reg_amd_thermtrip_status_desc reg_tts;=0A= uint32_t val;=0A= =0A= reg_tts.u32 =3D 0;=0A= if (0 =3D=3D (sc->tts_flags & AMDTEMP_TTS_F_CS_SWAP))=0A= reg_tts.bits.ThermSenseCoreSel =3D ((0 !=3D core) ? 1 : 0);=0A= else /* Swap. */=0A= reg_tts.bits.ThermSenseCoreSel =3D ((0 !=3D core) ? 0 : 1);=0A= reg_tts.bits.ThermSenseSel =3D ((0 !=3D sense) ? 1 : 0);=0A= =0A= AMDTEMP_LOCK(sc);=0A= pci_write_config(sc->dev, reg, reg_tts.u32, 4);=0A= reg_tts.u32 =3D pci_read_config(sc->dev, reg, 4);=0A= AMDTEMP_UNLOCK(sc);=0A= =0A= val =3D reg_tts.bits.CurTmp;=0A= if (0 =3D=3D (sc->tts_flags & AMDTEMP_TTS_F_CT_10BIT))=0A= val &=3D ~3; /* Clear first 2 bits. */=0A= val =3D (AMDTEMP_ZERO_C_TO_K + ((val * 5) / 2) -=0A= ((0 !=3D (sc->tts_flags & AMDTEMP_TTS_F_OFF28)) ? 280 : 490));=0A= val +=3D (sc->tts_temp_offset[((reg_tts.bits.ThermSenseCoreSel << 1) |=0A= reg_tts.bits.ThermSenseSel)] * 10);=0A= =0A= return (val);=0A= }=0A= /* If 0xff =3D=3D ARG2_GET_A2(arg2) then retun max temp for core. */=0A= static int=0A= amdtemp_tts_temp_reg_sysctl(SYSCTL_HANDLER_ARGS) {=0A= struct amdtemp_softc *sc =3D arg1;=0A= uint32_t reg_num;=0A= unsigned val;=0A= int error;=0A= =0A= reg_num =3D ARG2_GET_REG(arg2);=0A= if (0xff =3D=3D ARG2_GET_A2(arg2)) {=0A= val =3D imax(amdtemp_tts_get_temp(sc, reg_num, ARG2_GET_A1(arg2), 0),=0A= amdtemp_tts_get_temp(sc, reg_num, ARG2_GET_A1(arg2), 1));=0A= } else {=0A= val =3D amdtemp_tts_get_temp(sc, reg_num, ARG2_GET_A1(arg2),=0A= ARG2_GET_A2(arg2));=0A= }=0A= error =3D sysctl_handle_int(oidp, &val, 0, req);=0A= if (0 !=3D error || NULL =3D=3D req->newptr)=0A= return (error);=0A= return (0);=0A= }=0A= =0A= =0A= /* D18F3xA4 Reported Temperature Control Register */=0A= static int=0A= amdtemp_rtc_temp_sysctl(SYSCTL_HANDLER_ARGS) {=0A= struct amdtemp_softc *sc =3D arg1;=0A= union reg_amd_rep_tmp_ctrl_desc reg_ctrl;=0A= uint32_t reg_num, bits_off;=0A= unsigned val;=0A= int error;=0A= =0A= reg_num =3D ARG2_GET_REG(arg2);=0A= bits_off =3D ARG2_GET_A1(arg2);=0A= =0A= AMDTEMP_LOCK(sc);=0A= reg_ctrl.u32 =3D pci_read_config(sc->dev, reg_num, 4);=0A= switch (bits_off) {=0A= case 16: /* CurTmpTjSel */=0A= reg_ctrl.bits.CurTmpTjSel =3D 3;=0A= break;=0A= case 21: /* CurTmp */=0A= reg_ctrl.bits.CurTmpTjSel =3D 0;=0A= break;=0A= }=0A= pci_write_config(sc->dev, reg_num, reg_ctrl.u32, 4);=0A= reg_ctrl.u32 =3D pci_read_config(sc->dev, reg_num, 4);=0A= if (bits_off =3D=3D 16) { /* CurTmpTjSel: switch back to CurTmp. */=0A= reg_ctrl.bits.CurTmpTjSel =3D 0;=0A= pci_write_config(sc->dev, reg_num, reg_ctrl.u32, 4);=0A= }=0A= AMDTEMP_UNLOCK(sc);=0A= =0A= val =3D (AMDTEMP_ZERO_C_TO_K + ((reg_ctrl.bits.CurTmp * 5) / 4));=0A= if (16 =3D=3D bits_off) /* CurTmpTjSel */=0A= val -=3D 490;=0A= else=0A= val +=3D (sc->rtc_temp_offset * 10);=0A= error =3D sysctl_handle_int(oidp, &val, 0, req);=0A= if (0 !=3D error || NULL =3D=3D req->newptr)=0A= return (error);=0A= //device_printf(sc->dev, "amdtemp_rtc_temp_sysctl: reg_num =3D %i, = bits_off =3D %i, val =3D %i, reg_ctrl.u32 =3D %i\n", reg_num, bits_off, = val, reg_ctrl.u32);=0A= //pci_write_config(sc->dev, reg_num, reg_ctrl.u32, 4);=0A= return (0);=0A= }=0A= =0A= =0A= /* Set SMBus-based sideband interface address: 0-7. */=0A= static void=0A= amdtemp_sbi_set_addr(struct amdtemp_softc *sc, uint32_t sbi_addr) {=0A= union reg_amd_sbi_ctrl_desc reg_ctrl;=0A= =0A= sbi_addr &=3D AMD_REG_SBI_ADDR_MASK;=0A= reg_ctrl.u32 =3D pci_read_config(sc->dev, AMD_REG_SBI_CTRL, 4);=0A= if (reg_ctrl.bits.SbiAddr =3D=3D sbi_addr) /* Is address allready set? = */=0A= return;=0A= reg_ctrl.bits.SbiAddr =3D sbi_addr;=0A= pci_write_config(sc->dev, AMD_REG_SBI_CTRL, reg_ctrl.u32, 4);=0A= }=0A= =0A= static uint32_t=0A= amdtemp_sbi_read(struct amdtemp_softc *sc, uint32_t sbi_addr, uint32_t = reg_addr) {=0A= uint32_t ret;=0A= =0A= AMDTEMP_LOCK(sc);=0A= amdtemp_sbi_set_addr(sc, sbi_addr);=0A= pci_write_config(sc->dev, AMD_REG_SBI_ADDR, reg_addr, 4);=0A= ret =3D pci_read_config(sc->dev, AMD_REG_SBI_DATA, 4);=0A= AMDTEMP_UNLOCK(sc);=0A= =0A= return (ret);=0A= }=0A= =0A= static int=0A= amdtemp_sbi_write(struct amdtemp_softc *sc, uint32_t sbi_addr, uint32_t = reg_addr,=0A= uint8_t data) {=0A= union reg_amd_sbi_ctrl_desc reg_ctrl;=0A= uint32_t data32 =3D data;=0A= =0A= AMDTEMP_LOCK(sc);=0A= amdtemp_sbi_set_addr(sc, sbi_addr);=0A= pci_write_config(sc->dev, AMD_REG_SBI_ADDR, reg_addr, 4);=0A= pci_write_config(sc->dev, AMD_REG_SBI_DATA, data32, 4);=0A= /* Wait write. */=0A= data32 =3D AMD_SBI_WRITE_TIMEOUT;=0A= while (data32 --) {=0A= reg_ctrl.u32 =3D pci_read_config(sc->dev, AMD_REG_SBI_CTRL, 4);=0A= if (0 !=3D reg_ctrl.bits.SbiRegWrDn)=0A= break;=0A= DELAY(100);=0A= }=0A= AMDTEMP_UNLOCK(sc);=0A= =0A= if (data32 =3D=3D 0) {=0A= device_printf(sc->dev, "timeout waiting for SBI write.\n");=0A= return (1);=0A= }=0A= return (0);=0A= }=0A= =0A= static int=0A= amdtemp_tsi_reg_sysctl(SYSCTL_HANDLER_ARGS) {=0A= struct amdtemp_softc *sc =3D arg1;=0A= uint32_t reg_data, reg_addr, sbi_addr;=0A= unsigned val;=0A= int error;=0A= =0A= reg_addr =3D ARG2_GET_REG(arg2);=0A= sbi_addr =3D (ARG2_GET_A2(arg2) & AMD_REG_SBI_ADDR_MASK);=0A= reg_data =3D amdtemp_sbi_read(sc, sbi_addr, reg_addr);=0A= val =3D reg_data;=0A= =0A= error =3D sysctl_handle_int(oidp, &val, 0, req);=0A= if (0 !=3D error || NULL =3D=3D req->newptr || val =3D=3D reg_data)=0A= return (error);=0A= return (amdtemp_sbi_write(sc, sbi_addr, reg_addr, val));=0A= }=0A= =0A= static int=0A= amdtemp_tsi_temp_reg_sysctl(SYSCTL_HANDLER_ARGS) {=0A= struct amdtemp_softc *sc =3D arg1;=0A= uint32_t reg_data_lo, reg_data_hi, sbi_addr;=0A= unsigned val;=0A= int error;=0A= =0A= sbi_addr =3D (ARG2_GET_A2(arg2) & AMD_REG_SBI_ADDR_MASK);=0A= reg_data_lo =3D amdtemp_sbi_read(sc, sbi_addr, ARG2_GET_REG(arg2));=0A= reg_data_hi =3D amdtemp_sbi_read(sc, sbi_addr, ARG2_GET_A1(arg2));=0A= val =3D (AMDTEMP_ZERO_C_TO_K + (reg_data_hi * 10));=0A= if (SB_TSI_REG_CPU_TEMP_LB =3D=3D ARG2_GET_REG(arg2)) /* Apply offset = only to sensor. */=0A= val +=3D (sc->tsi_temp_offset[sbi_addr] * 10);=0A= if (reg_data_lo & 0x80)=0A= val +=3D 5; /* 0,5 C */=0A= if (reg_data_lo & 0x40)=0A= val +=3D 3; /* 0,25 C */=0A= if (reg_data_lo & 0x20)=0A= val +=3D 1; /* 0,125 C */=0A= =0A= error =3D sysctl_handle_int(oidp, &val, 0, req);=0A= if (0 !=3D error || NULL =3D=3D req->newptr)=0A= return (error);=0A= return (0);=0A= }=0A= ------=_NextPart_000_0206_01CEC31D.875A19E0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 16:17:27 2013 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 ESMTP id C8F5EBA0; Mon, 7 Oct 2013 16:17:27 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 998872E6E; Mon, 7 Oct 2013 16:17:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD351B962; Mon, 7 Oct 2013 12:17:26 -0400 (EDT) From: John Baldwin To: Alexander Motin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking Date: Mon, 7 Oct 2013 12:09:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <5224511D.4090503@FreeBSD.org> <201310021330.23251.jhb@freebsd.org> <525111A2.1020106@FreeBSD.org> In-Reply-To: <525111A2.1020106@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201310071209.56312.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 Oct 2013 12:17:26 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:17:28 -0000 On Sunday, October 06, 2013 3:30:42 am Alexander Motin wrote: > On 02.10.2013 20:30, John Baldwin wrote: > > On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: > >> On 07.09.2013 02:02, Jeremie Le Hen wrote: > >>> On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: > >>>> On 06.09.2013 11:06, Jeremie Le Hen wrote: > >>>>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labb=E9 w= rote: > >>>>>> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin > > wrote: > >>>>>>> I've found and fixed possible double request completion, that cou= ld > > cause > >>>>>>> such symptoms if happened. Updated patch located as usual: > >>>>>>>=20 http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch > >>>>>>> > >>>>> With this new one I cannot boot any more (I also updated the source > >>>>> tree). This is a hand transcripted version: > >>>>> > >>>>> Trying to mount root from zfs:zroot/root []... > >>>>> panic: Batch flag already set > >>>>> cpuid =3D 1 > >>>>> KDB: stack backtrace: > >>>>> db_trace_self_wrapper() > >>>>> kdb_backtrace() > >>>>> vpanic() > >>>>> kassert_panic() > >>>>> xpt_batch_start() > >>>>> ata_interrupt() > >>>>> softclock_call_cc() > >>>>> softclock() > >>>>> ithread_loop() > >>>>> fork_exit() > >>>>> fork_trampoline() > >>>> > >>>> Thank you for the report. I see my fault. It is probably specific to > >>>> ata(4) driver only. I've workarounded that in new patch version, but > >>>> probably that area needs some rethinking. > >>>> > >>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch > >>> > >>> I'm not sure you needed a confirmation, but it boots. Thanks :). > >>> > >>> I didn't quite understand the thread; is direct dispatch enabled for > >>> amd64? ISTR you said only i386 but someone else posted the macro for > >>> amd64. > >> > >> Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd= 64. > > > > FYI, I tested mfi with this patch set and mfid worked fine for handling= =20 g_up > > directly: > > > > Index: dev/mfi/mfi_disk.c > > =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 > > --- dev/mfi/mfi_disk.c (revision 257407) > > +++ dev/mfi/mfi_disk.c (working copy) > > @@ -162,6 +162,7 @@ > > sc->ld_disk->d_unit =3D sc->ld_unit; > > sc->ld_disk->d_sectorsize =3D secsize; > > sc->ld_disk->d_mediasize =3D sectors * secsize; > > + sc->ld_disk->d_flags =3D DISKFLAG_DIRECT_COMPLETION; > > if (sc->ld_disk->d_mediasize >=3D (1 * 1024 * 1024)) { > > sc->ld_disk->d_fwheads =3D 255; > > sc->ld_disk->d_fwsectors =3D 63; > > >=20 > Thank you for the feedback. But looking on mfi driver sources I would=20 > say that it calls biodone() from mfi_disk_complete() from cm_complete()=20 > method, which is called while holding mfi_io_lock mutex. I guess that if= =20 > on top of mfi device would be some GEOM class, supporting direct=20 > dispatch and sending new requests down on previous request completion=20 > (or retrying requests), that could cause recursive mfi_io_lock=20 > acquisition. That is exactly the cause why I've added this flag. May be=20 > it is a bit paranoid, but it is better to be safe then sorry. >=20 > Another good reason to drop the lock before calling biodone() would be=20 > reducing the lock hold time. Otherwise it may just increase lock=20 > congestion there and destroy all benefits of the direct dispatch. Ah, interesting. What is your policy for such drivers? Should they be left using g_up, should they drop the lock around biodone when completeing multiple requests in an interrupt? Should they try to batch them by waiting and doing biodone at the end after dropping the lock? =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 16:17:29 2013 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 ESMTP id 6AADDBA3 for ; Mon, 7 Oct 2013 16:17:29 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 45BAE2E70 for ; Mon, 7 Oct 2013 16:17:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3608DB99B; Mon, 7 Oct 2013 12:17:28 -0400 (EDT) From: John Baldwin To: rank1seeker@gmail.com Subject: Re: UFS related panic (daily <-> find) Date: Mon, 7 Oct 2013 12:12:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20130719.174511.786.3@DOMY-PC> <201310021702.49174.jhb@freebsd.org> <20131002.214002.280.2@DOMY-PC> In-Reply-To: <20131002.214002.280.2@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201310071212.05281.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 Oct 2013 12:17:28 -0400 (EDT) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:17:29 -0000 On Wednesday, October 02, 2013 5:40:02 pm rank1seeker@gmail.com wrote: > > > > > Ok, here is another one, same case, just this time under > 9.1-RELEASE-p7 > > > > > > > > > > ============================================== > > > > > Fatal trap 12: page fault while in kernel mode > > > > > fault virtual address = 0x25 > > > > > fault code = supervisor read, page not present > > > > > instruction pointer = 0x20:0xc082c552 > > > > > stack pointer = 0x28:0xe7eed7a8 > > > > > frame pointer = 0x28:0xe7eed7ac > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > current process = 63645 (find) > > > > > trap number = 12 > > > > > panic: page fault > > > > > Uptime: 11h16m47s > > > > > Physical memory: 1014 MB > > > > > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > > > > > > > > > #6 0xc0898d4c in calltrap () at > /usr/src/sys/i386/i386/exception.s:169 > > > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" > is > > > not > > > > > available. > > > > > ) > > > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > > > > > Please go to frame 7 and do 'x/i $rip'. > > > > > > > > > > (kgdb) up 7 > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is > not > > > available. > > > ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > 2073 /usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory. > > > in /usr/src/sys/ufs/ffs/ffs_softdep.c > > > (kgdb) x/i $rip > > > Value can't be converted to integer. > > > > Oh, this is i386, use "$eip" instead of "$rip", so 'x/i $eip' at frame 7. > > > (kgdb) x/i $eip > 0xc082c552 : cmp %ecx,0x24(%eax) Ok, so %eax must be 1. I think you probably have failing RAM with a stuck bit or some such. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 16:44:40 2013 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 ESMTP id 0E2CC951; Mon, 7 Oct 2013 16:44:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) 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 18D0C20BB; Mon, 7 Oct 2013 16:44:38 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b45so3411643eek.15 for ; Mon, 07 Oct 2013 09:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=35KWtTscl4vVGFofXojrrZELOiiZi7dj5Nw0m1SbJ74=; b=j51PA/X69Fs1qIT6aHHz1NvmV/+dUI22Nyqg0kq6Hm+aFiE61IqvFwB9h6xQIHw18U JIhtfFT8gG9gqEDJlWOUWS/b8G9kxIAcAIR7ayN42AzeEtR/zFnNVM5sxKjFX3wFJdGL /gpTUO4MWCIZRpdR/4Oc736lBJUy2RkPz2N53WZUS5C+XNuOGE1xOFyrAfWP1Hkj3kbO b64oi17jwW/F1h2T/0H1TB9lCSy8VgtKRsG2q9WGRZz7/ymbknp3n3okhOJZkI17zW0j rusZntKOpLwDPivPpfPebhkV2RY+eGSpCsZAKvgMXUepIBuYUm52+TyyOHWoQ26AcmWM 3qqQ== X-Received: by 10.14.88.65 with SMTP id z41mr49832497eee.38.1381164277446; Mon, 07 Oct 2013 09:44:37 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([46.211.77.102]) by mx.google.com with ESMTPSA id r48sm65342167eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 09:44:36 -0700 (PDT) Sender: Alexander Motin Message-ID: <5252E4F1.9070604@FreeBSD.org> Date: Mon, 07 Oct 2013 19:44:33 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking References: <5224511D.4090503@FreeBSD.org> <201310021330.23251.jhb@freebsd.org> <525111A2.1020106@FreeBSD.org> <201310071209.56312.jhb@freebsd.org> In-Reply-To: <201310071209.56312.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:44:40 -0000 On 07.10.2013 19:09, John Baldwin wrote: > On Sunday, October 06, 2013 3:30:42 am Alexander Motin wrote: >> On 02.10.2013 20:30, John Baldwin wrote: >>> On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: >>>> On 07.09.2013 02:02, Jeremie Le Hen wrote: >>>>> On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: >>>>>> On 06.09.2013 11:06, Jeremie Le Hen wrote: >>>>>>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labb� wrote: >>>>>>>> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin >>> wrote: >>>>>>>>> I've found and fixed possible double request completion, that could >>> cause >>>>>>>>> such symptoms if happened. Updated patch located as usual: >>>>>>>>> > http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch >>>>>>>>> >>>>>>> With this new one I cannot boot any more (I also updated the source >>>>>>> tree). This is a hand transcripted version: >>>>>>> >>>>>>> Trying to mount root from zfs:zroot/root []... >>>>>>> panic: Batch flag already set >>>>>>> cpuid = 1 >>>>>>> KDB: stack backtrace: >>>>>>> db_trace_self_wrapper() >>>>>>> kdb_backtrace() >>>>>>> vpanic() >>>>>>> kassert_panic() >>>>>>> xpt_batch_start() >>>>>>> ata_interrupt() >>>>>>> softclock_call_cc() >>>>>>> softclock() >>>>>>> ithread_loop() >>>>>>> fork_exit() >>>>>>> fork_trampoline() >>>>>> >>>>>> Thank you for the report. I see my fault. It is probably specific to >>>>>> ata(4) driver only. I've workarounded that in new patch version, but >>>>>> probably that area needs some rethinking. >>>>>> >>>>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch >>>>> >>>>> I'm not sure you needed a confirmation, but it boots. Thanks :). >>>>> >>>>> I didn't quite understand the thread; is direct dispatch enabled for >>>>> amd64? ISTR you said only i386 but someone else posted the macro for >>>>> amd64. >>>> >>>> Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd64. >>> >>> FYI, I tested mfi with this patch set and mfid worked fine for handling > g_up >>> directly: >>> >>> Index: dev/mfi/mfi_disk.c >>> =================================================================== >>> --- dev/mfi/mfi_disk.c (revision 257407) >>> +++ dev/mfi/mfi_disk.c (working copy) >>> @@ -162,6 +162,7 @@ >>> sc->ld_disk->d_unit = sc->ld_unit; >>> sc->ld_disk->d_sectorsize = secsize; >>> sc->ld_disk->d_mediasize = sectors * secsize; >>> + sc->ld_disk->d_flags = DISKFLAG_DIRECT_COMPLETION; >>> if (sc->ld_disk->d_mediasize >= (1 * 1024 * 1024)) { >>> sc->ld_disk->d_fwheads = 255; >>> sc->ld_disk->d_fwsectors = 63; >>> >> >> Thank you for the feedback. But looking on mfi driver sources I would >> say that it calls biodone() from mfi_disk_complete() from cm_complete() >> method, which is called while holding mfi_io_lock mutex. I guess that if >> on top of mfi device would be some GEOM class, supporting direct >> dispatch and sending new requests down on previous request completion >> (or retrying requests), that could cause recursive mfi_io_lock >> acquisition. That is exactly the cause why I've added this flag. May be >> it is a bit paranoid, but it is better to be safe then sorry. >> >> Another good reason to drop the lock before calling biodone() would be >> reducing the lock hold time. Otherwise it may just increase lock >> congestion there and destroy all benefits of the direct dispatch. > > Ah, interesting. What is your policy for such drivers? Should they be > left using g_up, should they drop the lock around biodone when completeing > multiple requests in an interrupt? Should they try to batch them by > waiting and doing biodone at the end after dropping the lock? In CAM's da and ada drivers I've managed to drop the periph lock before calling biodone(). New CAM locking design allowed to do it safe. Possibility of dropping CAM SIM (HBA driver) locks on completion though depends on HBA design. For example, for ATA/SATA drivers I haven't found safe way to drop the lock in place, so I delay commands completions up to the moment when lock can be safely dropped and then process completions in a batch. For SCSI HBAs with more separated request and response queues I guess that may be easier. But now all SCSI drivers are still queuing requests completion to separate CAM threads to decouple the locks that way. I've just added more of them to spread the load between cores. But I hope that, for example, mps driver could be reworked to allow both using multiple MSI-X interrupt threads and lock-less request completion. Whether it is possible to do it safe for mfi I don't know. For cases when dropping the locks is not possible, there is g_up thread to use. For setups with single controller in a system with single interrupt thread queuing to g_up thread may even be better, helping to split load between two CPUs instead of one. But that is in case if HBA is fast or ineffective enough to saturate one CPU. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 17:25:24 2013 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 ESMTP id C5938FE1; Mon, 7 Oct 2013 17:25:24 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61C632381; Mon, 7 Oct 2013 17:25:24 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id jx11so3794754veb.7 for ; Mon, 07 Oct 2013 10:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=77/FGlPtJQikkCNyMtJj5PGGj3kDDBVKXvfteIN4PFw=; b=K3QXpGYPoIhKtwElQDiSPcbxPOgLHVlj647bqPOF+qzli7E0Jgm3lijpw6wTPW2P73 TsDXckVaUYyBaRieOA370Govn568XKf2kvpk0BzapVhXSwwrmHRev41LFh5UeUIguSOh 6O/uhtt50FXEgyk8GahQ7tdSQOUriwp7m8Kg7FJ2QjZ+E1K9rQxOM6Jx5pMnHZfqykwI pMfYeNnNG8TzNpYSAa1Jz4j8kWA6YFJr3YBABPJB9PpreErhKtc06WDf1Nc2EDmwqMgJ B9t2c8r8Gz+GcEudBytg+GhbHaFVkMCQ5KKtd15IIXca6he4UBQWVFFHJu1RTbIrShcl QZgA== MIME-Version: 1.0 X-Received: by 10.220.110.6 with SMTP id l6mr831498vcp.28.1381166723442; Mon, 07 Oct 2013 10:25:23 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Mon, 7 Oct 2013 10:25:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 19:25:23 +0200 X-Google-Sender-Auth: cEoomBk3YXNvobK7q4CgSDta6XQ Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:25:24 -0000 On Wed, Aug 28, 2013 at 3:56 PM, Ivan Voras wrote: > Hi, > > Prodded by davide@, I'd like to collect opinions about raising the > vfs.ufs.dirhash_reclaimage sysctl from 5 to 60, committed at: > > http://svnweb.freebsd.org/changeset/base/254986 > > What it does: > > Used in lowmem handler at > http://fxr.watson.org/fxr/source/ufs/ufs/ufs_dirhash.c#L1247 when > determining which cache entries to evict; it skips (keeps in the cache) > entries which are younger than this number of seconds. This lowmem > handler only frees up to 10% of the dirhash cache at a time. > I don't think this is correct. The first loop scans over the whole ufsdirhash_list and there's nothing that sets the cap to 10%. It might happen that UFS is unused for some minutes and you'll end up with all the cache free'd. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 17:34:27 2013 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 ESMTP id 4CE9C57C; Mon, 7 Oct 2013 17:34:27 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E951244B; Mon, 7 Oct 2013 17:34:26 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id hv10so2981185vcb.8 for ; Mon, 07 Oct 2013 10:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vwvLFqEb9U3hPhbAAIAXI33/t4DokjslzkbwD0tEOEE=; b=B5D5qdgZjOLI4OvC4CfkONMBr1HebyTvBJN677fjR3J3rsr856MBtJAcRSywS4z+jW xdlksiBjabW1pa/ea99ZCpjb6goYfU+FwLTzWaTwgFLs3g5fkeD6UWm6db/7qL8lah7L xGhszWNNx3agaqjcqDKdK9v/ejtTGnG6iGEEmp6EHkWQq1cIRj44OEuy6Qcdmn4AKTO3 kKBJbdGYpR305Ks/245FGjbVRRh9cWfNrJVzdB5x5dZiwINplxwj35dxBkTyTA6XZniu JEQzSV9c03/LGcaemMvS9Vf87E1QR7rfSMa5cjLjLOKoeuQm3KHy0EbsiXH/W+cXCLjo r18A== MIME-Version: 1.0 X-Received: by 10.221.44.136 with SMTP id ug8mr27375118vcb.13.1381167265028; Mon, 07 Oct 2013 10:34:25 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Mon, 7 Oct 2013 10:34:24 -0700 (PDT) In-Reply-To: <201309031507.33098.jhb@freebsd.org> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> Date: Mon, 7 Oct 2013 19:34:24 +0200 X-Google-Sender-Auth: JQDCy-MSqtcuvUVwEdRZlUXTzvU Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , alc@freebsd.org, freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras , pho@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:34:27 -0000 > What would perhaps be better than a hardcoded reclaim age would be to use > an LRU-type approach and perhaps set a target percent to reclaim. That is, > suppose you were to reclaim the oldest 10% of hashes on each lowmem call > (and make the '10%' the tunable value). Then you will always make some amount > of progress in a low memory situation (and if the situation remains dire you > will eventually empty the entire cache), but the effective maximum age will > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > throws the entire thing out on the first lowmem event. The LRU-approach would > only throw the oldest 10% out on the first call, but eventually throw it all out > if the situation remains dire. > > -- > John Baldwin > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" I liked your idea more than what's available in HEAD right now and I implemented it. http://people.freebsd.org/~davide/review/ufs_direclaimage.diff I was unsure what kind of heuristic I should choose to select which (10% of) entries should be evicted so I just removed the first 10% ones from the head of the ufs_dirhash list (which should be the oldest). The code keeps rescanning the cache until 10% (or, the percentage set via SYSCTL) of the entry are freed, but probably we can discuss if this limit could be relaxed and just do a single scan over the list. Unfortunately I haven't a testcase to prove the effectiveness (or non-effectiveness) of the approach but I think either Ivan or Peter could be able to give it a spin, maybe. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 18:34:05 2013 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 ESMTP id 3670ACF6; Mon, 7 Oct 2013 18:34:05 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A32902856; Mon, 7 Oct 2013 18:34:04 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id k14so7714469wgh.25 for ; Mon, 07 Oct 2013 11:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:in-reply-to:references; bh=yWmPrAbUAEMuHzMoZ6H3ZAUt6Zw80G5771ka4XC80oU=; b=vtnPULQfURC6TbDT5zN5ROQVYBSBcg4A/IHnUyp8G2yJx726wPy+rJdg9hzWDYmEYZ dR4IQShBvuS4plk9p084HA1WsesChYdH5VvdAHmSR6fOuJgatXgBxdYo9KV8IKYqeV1W xXjRCdM0F0eZJvpa5gDx7a8WLB2okZLeMRURXv8gDCj+AIvnX67N4szZ7uIcAv3uUPEy SLM6hRQGOKf5HytEREAqLH0CiWWBC100ZTQ8sUFGWE5r+3KUK4XDfIJBS3JwC/8KKIhc stZpvV07glZhZ9N57KLVs2OhDsRQCJWtb099iD/KPpHC1oe1zJDnhwadOeRcwUXf/WVK vb1w== X-Received: by 10.180.185.203 with SMTP id fe11mr20018746wic.29.1381170843081; Mon, 07 Oct 2013 11:34:03 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id ey4sm42006874wic.11.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 07 Oct 2013 11:34:02 -0700 (PDT) Message-ID: <20131007.183359.947.1@DOMY-PC> From: rank1seeker@gmail.com To: "John Baldwin" Subject: Re: UFS related panic (daily <-> find) Date: Mon, 07 Oct 2013 20:33:59 +0200 In-Reply-To: <201310071212.05281.jhb@freebsd.org> References: <20130719.174511.786.3@DOMY-PC> <201310021702.49174.jhb@freebsd.org> <20131002.214002.280.2@DOMY-PC> <201310071212.05281.jhb@freebsd.org> X-Mailer: POP Peeper (3.8.1.0) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 18:34:05 -0000 > On Wednesday, October 02, 2013 5:40:02 pm rank1seeker@gmail.com wrote: > > > > > > Ok, here is another one, same case, just this time under > > 9.1-RELEASE-p7 > > > > > > > > > > > > ============================================== > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > fault virtual address = 0x25 > > > > > > fault code = supervisor read, page not present > > > > > > instruction pointer = 0x20:0xc082c552 > > > > > > stack pointer = 0x28:0xe7eed7a8 > > > > > > frame pointer = 0x28:0xe7eed7ac > > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > > current process = 63645 (find) > > > > > > trap number = 12 > > > > > > panic: page fault > > > > > > Uptime: 11h16m47s > > > > > > Physical memory: 1014 MB > > > > > > Dumping 143 MB: 128 112 96 80 64 48 32 16 > > > > > > > > > > > > #6 0xc0898d4c in calltrap () at > > /usr/src/sys/i386/i386/exception.s:169 > > > > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" > > is > > > > not > > > > > > available. > > > > > > ) > > > > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > > > > > > > Please go to frame 7 and do 'x/i $rip'. > > > > > > > > > > > > > (kgdb) up 7 > > > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is > > not > > > > available. > > > > ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073 > > > > 2073 /usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory. > > > > in /usr/src/sys/ufs/ffs/ffs_softdep.c > > > > (kgdb) x/i $rip > > > > Value can't be converted to integer. > > > > > > Oh, this is i386, use "$eip" instead of "$rip", so 'x/i $eip' at frame 7. > > > > > > (kgdb) x/i $eip > > 0xc082c552 : cmp %ecx,0x24(%eax) > > Ok, so %eax must be 1. I think you probably have failing RAM with a stuck bit > or some such. > Today I've just finished HDD scan with recoverdisk and there were 3 bad sectors. It was stuck on them for a 15 hrs, until it finally did read whole disk, Then I've run it again and it read HDD 100%, without a glitch. I don't know was it a firmware realocated those or those looooong read attempts fixed a thing. Then reboted into single user and run fsck, which detected a LOT unreferenced inodes at /usr, which it successfully reconected. Finally fsck again to get clean, non error output. Could that caused a panics? PS: I'll run a memtest86+ when I get some time. For how long do you advise? Domagoj From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 19:14:09 2013 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 ESMTP id 8CE55F1 for ; Mon, 7 Oct 2013 19:14:09 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E749D2B05 for ; Mon, 7 Oct 2013 19:14:08 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id r97JBwdp002498 for ; Mon, 7 Oct 2013 21:11:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id r97JBwwx002495 for ; Mon, 7 Oct 2013 21:11:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 7 Oct 2013 21:11:58 +0200 (CEST) From: Wojciech Puchar To: hackers@freebsd.org Subject: geli still broken on latest 9.* from svn Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 07 Oct 2013 21:11:58 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:14:09 -0000 is it planned to fix or should i just treat some non latest 9.* release as the last non-broken one, and just apply security fixes manually? From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 20:17:33 2013 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 ESMTP id 9D0C5CF9 for ; Mon, 7 Oct 2013 20:17:33 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76F402F8A for ; Mon, 7 Oct 2013 20:17:33 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id un15so7643074pbc.15 for ; Mon, 07 Oct 2013 13:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=kEjnujZderi0Wzj6Az5180kDzNLUoHE2J2cigkxdoVI=; b=FV2BCUCvQ4uzlYJasxFJfY5giAQal9g1eOr90S8O6zn81NK+njUwR9y5UgxfrKYOVL CtSnTxjuMDVqS/L4Ttki3RyMmcT4CS/caiGH1/EnBZTK7TraO2rtdTMYhq7w7FY7M1NI 5qTwNYKMhO7OtkBUVIqNSc3dE76IKL63ZoU78= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=kEjnujZderi0Wzj6Az5180kDzNLUoHE2J2cigkxdoVI=; b=FJ1DZzPrVFgyAXO5BvC0M2LRlqr5g4FdNR8zwRoP8ohnVyGFdAolM2D5DMn4X9CXdE vuaGXXKhFKeeXFwcmBNneTifaZxEtHc42NQZF5q0dUeNUTnWI0bv0Bx+dS0FXroVvbQd MjE0l0mY5PoFdwhV3+g/viwo1Hhs4BtiT1qo65ZKfqZ0/TPL7CShqkr3akVIUXF5Qmhg xcpAX57i6yvlmgkJKpkPMf9XnaND7OuE7STCvFdhiuHC7UY967AjhcUGMLGXlP8MyVk6 5qZmPCEFbfAQf+1NG8WseIth9FnFRwKeM7m6XQzNAgVwArBlY6eEQTSzFH2480pH2U5C pHYQ== X-Gm-Message-State: ALoCoQl2PhNxk6L3hbdUnpgzhDdpa9c61k4Sj/bRujORp/MjwjB1qlq7AxVvGnZZoD7S4BGmleQX X-Received: by 10.66.156.199 with SMTP id wg7mr33820428pab.81.1381177053196; Mon, 07 Oct 2013 13:17:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.6.3 with HTTP; Mon, 7 Oct 2013 13:17:03 -0700 (PDT) From: Eitan Adler Date: Mon, 7 Oct 2013 16:17:03 -0400 Message-ID: Subject: patch(1) depends on RCS - should it? To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:17:33 -0000 patch(1) explicitly tries to use RCS (and SCCS) in certain cases. Are we okay with a base system utility that behaves differently depending on whether a port is installed? Should the relevant code be removed from patch(1)? See head/usr.bin/patch/inp.c lines 166 to 240 for details. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 7 20:46:48 2013 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 ESMTP id 4CE421D1 for ; Mon, 7 Oct 2013 20:46:48 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1389721F4 for ; Mon, 7 Oct 2013 20:46:47 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 456303EA02; Mon, 7 Oct 2013 20:46:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r97KkjHe000816; Mon, 7 Oct 2013 20:46:46 GMT (envelope-from phk@phk.freebsd.dk) To: Eitan Adler Subject: Re: patch(1) depends on RCS - should it? In-reply-to: From: "Poul-Henning Kamp" References: Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 07 Oct 2013 20:46:45 +0000 Message-ID: <815.1381178805@critter.freebsd.dk> X-Mailman-Approved-At: Mon, 07 Oct 2013 21:02:49 +0000 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:46:48 -0000 In message , Eitan Adler writes: >patch(1) explicitly tries to use RCS (and SCCS) in certain cases. Are >we okay with a base system utility that behaves differently depending >on whether a port is installed? Should the relevant code be removed >from patch(1)? > >See head/usr.bin/patch/inp.c lines 166 to 240 for details. Yes, that code should be removed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 06:34:36 2013 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 ESMTP id A5ED6FED for ; Tue, 8 Oct 2013 06:34:36 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 5B56A2707 for ; Tue, 8 Oct 2013 06:34:36 +0000 (UTC) Received: (qmail 39690 invoked from network); 8 Oct 2013 06:34:34 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay02.pair.com with SMTP; 8 Oct 2013 06:34:34 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r986YXoK048149; Tue, 8 Oct 2013 08:34:33 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r986YXSb048148; Tue, 8 Oct 2013 08:34:33 +0200 (CEST) (envelope-from pho) Date: Tue, 8 Oct 2013 08:34:33 +0200 From: Peter Holm To: Davide Italiano Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <20131008063433.GA47506@x2.osted.lan> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kirk McKusick , alc@freebsd.org, freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 06:34:36 -0000 On Mon, Oct 07, 2013 at 07:34:24PM +0200, Davide Italiano wrote: > > What would perhaps be better than a hardcoded reclaim age would be to use > > an LRU-type approach and perhaps set a target percent to reclaim. That is, > > suppose you were to reclaim the oldest 10% of hashes on each lowmem call > > (and make the '10%' the tunable value). Then you will always make some amount > > of progress in a low memory situation (and if the situation remains dire you > > will eventually empty the entire cache), but the effective maximum age will > > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > > throws the entire thing out on the first lowmem event. The LRU-approach would > > only throw the oldest 10% out on the first call, but eventually throw it all out > > if the situation remains dire. > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > I liked your idea more than what's available in HEAD right now and I > implemented it. > http://people.freebsd.org/~davide/review/ufs_direclaimage.diff > I was unsure what kind of heuristic I should choose to select which > (10% of) entries should be evicted so I just removed the first 10% > ones from the head of the ufs_dirhash list (which should be the > oldest). > The code keeps rescanning the cache until 10% (or, the percentage set > via SYSCTL) of the entry are freed, but probably we can discuss if > this limit could be relaxed and just do a single scan over the list. > Unfortunately I haven't a testcase to prove the effectiveness (or > non-effectiveness) of the approach but I think either Ivan or Peter > could be able to give it a spin, maybe. > I gave this patch a spin for 12 hours without finding any problems. I can do more testing at a later time, if you want to. - Peter From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 10:22:00 2013 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 ESMTP id 0A368E6B for ; Tue, 8 Oct 2013 10:22:00 +0000 (UTC) (envelope-from admin@3dr.org) Received: from futurehost.futurehost.pl (futurehost.futurehost.pl [91.200.185.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDCC72627 for ; Tue, 8 Oct 2013 10:21:59 +0000 (UTC) Received: from afst9.neoplus.adsl.tpnet.pl ([178.42.227.9]:10255 helo=ukaszBright) by futurehost.futurehost.pl with esmtpa (Exim 4.80) (envelope-from ) id 1VTUQO-0009hg-GU for freebsd-hackers@freebsd.org; Tue, 08 Oct 2013 12:21:56 +0200 From: =?iso-8859-2?Q?=A3ukasz_P?= To: Subject: Fuse on FreeBSD 9.2 Date: Tue, 8 Oct 2013 12:21:55 +0200 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7EEBnftDAwCnT0RCKcLmH+zy35WQ== Content-Language: pl X-Mailman-Approved-At: Tue, 08 Oct 2013 11:23:09 +0000 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:22:00 -0000 Hello, Please let me know if anyone is up to fix fuse on FreeBSD 9.x ? Particularly this bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=182739 I'm willing to pay for the fix. Thank you, Luke From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 11:25:56 2013 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 ESMTP id 57789478; Tue, 8 Oct 2013 11:25:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AFF032A2A; Tue, 8 Oct 2013 11:25:55 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id x19so5791072qcw.16 for ; Tue, 08 Oct 2013 04:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GTkq7YZP3xrS5a8abx+BYxsqk9e0kg+3EXianFQwyTY=; b=C0bYUk3GX4uR1roZj6IxAQCtNz5xlZnyAbjguIBopr1UsQ14Z7B54dfyt1MHiaQVhe XIgT53Q9ID6c9w1B2cT3kJKPgExKOR9sGYSMst9tXuZTo1t8m+15m+gj9JmOuZ3vnET/ HIYde8haYlyYdtHkp9Pwm/7YbObzMl8Fe9rMsjppKgi4mswgXRj62lesZMNHoaMPAmnz O2eK3SWdQZinHlF7s2txEWVC8fYC2rKhpcV1ZFPiIGbG93SGEciM1EXe/M+/I246l+Mv UC/o5EN4awuluPKpVa1Cbs6yjW3KWSx1mc4jr78gDQdmsgJcekOy0GE/fGjmAJFgTGz5 bBxA== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr2957666qad.76.1381231554854; Tue, 08 Oct 2013 04:25:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 8 Oct 2013 04:25:54 -0700 (PDT) In-Reply-To: <20131008063433.GA47506@x2.osted.lan> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> Date: Tue, 8 Oct 2013 04:25:54 -0700 X-Google-Sender-Auth: wahWjwqMNpWYLAzRpvhNwymuofc Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Adrian Chadd To: Peter Holm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Davide Italiano , Kirk McKusick , Alan Cox , freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:25:56 -0000 Hi, Please try it out on a -10 VM with something RAM limited - say, 128mb w/ GENERIC. See how it behaves. I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not to break that before releng/10 is cut. thanks, -adrian On 7 October 2013 23:34, Peter Holm wrote: > On Mon, Oct 07, 2013 at 07:34:24PM +0200, Davide Italiano wrote: > > > What would perhaps be better than a hardcoded reclaim age would be to > use > > > an LRU-type approach and perhaps set a target percent to reclaim. > That is, > > > suppose you were to reclaim the oldest 10% of hashes on each lowmem > call > > > (and make the '10%' the tunable value). Then you will always make > some amount > > > of progress in a low memory situation (and if the situation remains > dire you > > > will eventually empty the entire cache), but the effective maximum age > will > > > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > > > throws the entire thing out on the first lowmem event. The > LRU-approach would > > > only throw the oldest 10% out on the first call, but eventually throw > it all out > > > if the situation remains dire. > > > > > > -- > > > John Baldwin > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > I liked your idea more than what's available in HEAD right now and I > > implemented it. > > http://people.freebsd.org/~davide/review/ufs_direclaimage.diff > > I was unsure what kind of heuristic I should choose to select which > > (10% of) entries should be evicted so I just removed the first 10% > > ones from the head of the ufs_dirhash list (which should be the > > oldest). > > The code keeps rescanning the cache until 10% (or, the percentage set > > via SYSCTL) of the entry are freed, but probably we can discuss if > > this limit could be relaxed and just do a single scan over the list. > > Unfortunately I haven't a testcase to prove the effectiveness (or > > non-effectiveness) of the approach but I think either Ivan or Peter > > could be able to give it a spin, maybe. > > > > I gave this patch a spin for 12 hours without finding any problems. > I can do more testing at a later time, if you want to. > > - Peter > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 11:33:00 2013 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 ESMTP id 70213ABF; Tue, 8 Oct 2013 11:33:00 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C489D2AD2; Tue, 8 Oct 2013 11:32:59 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id e13so4242044vbg.31 for ; Tue, 08 Oct 2013 04:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OuHr7TWex/Sbadt7vrAlQRrC2ZPkTHCJis0MrkCsIBA=; b=T4onWRFk4+At0+tuuBRE2i1hM2AjKVhDBYeNXu45f7FK9EJZnrwOz/8Z08fscGFoj+ /MjIL2EumB5pfHQZD5HCw1jWVuJO69U3zeq3Pg+v+cPDI27e4tzJvoOBcXQGfbp1CMr+ v8zHA2IJAxmbL8OjSQB8FA5t9wm05ZAF/WdDsKt2RILsoH0NFj5DXXUKq8qZF8LpO8Jd TywhP0OByWyd1G3fjXvuSV0jZhwR8/B1nRvKG1J+YoMMLOqJe19aw/JdC+Tn79PsaGDT 5mOZ0HWPzH9P7c7YVmt5+YZ75bXqMoCz91B6+18O3KX/AQoZfa2qdYgLMe4QYigVt5Rd e/rQ== MIME-Version: 1.0 X-Received: by 10.220.188.66 with SMTP id cz2mr659434vcb.33.1381231978876; Tue, 08 Oct 2013 04:32:58 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 8 Oct 2013 04:32:58 -0700 (PDT) In-Reply-To: References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> Date: Tue, 8 Oct 2013 13:32:58 +0200 X-Google-Sender-Auth: 7APWatQsQOZLqatgZexpPWzu7rc Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , Alan Cox , Peter Holm , freebsd-fs@freebsd.org, Ivan Voras , freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:33:00 -0000 On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd wrote: > Hi, > Hi Adrian, > Please try it out on a -10 VM with something RAM limited - say, 128mb w/ > GENERIC. See how it behaves. > > I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not > to break that before releng/10 is cut. > > thanks, > > This is not supposed to hit 10-STABLE, at least not before proper review. This is the reason why it was proposed on mailing lists. Also, if you read the patch you'll end up with realizing this should behave better on low memory environment because it unconditionally cleans 10% of the cache every time. Previous changes in this area just did the opposite keeping a lot more of memory around. I hope this makes sense to you. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 11:34:04 2013 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 ESMTP id 74FB6D22 for ; Tue, 8 Oct 2013 11:34:04 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49E0A2B03 for ; Tue, 8 Oct 2013 11:34:04 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7BA24211F9 for ; Tue, 8 Oct 2013 07:34:03 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 08 Oct 2013 07:34:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=JSEDQQvIskyMy+iFieyBno6908w=; b=FOp pOH23HdfMqtxlG8vK0zUQYO2Fzxzg37IQUSId2WvXCSdcIyN60vKJ9eW9IopE/I3 B6mtDTWO0sWkQ2BxElLOs/k/HawTRJG5XRF7jPC2FGfbeNTiQWiJsfECeeX9bMGN 0v0HR7Gee7zNk06R+HW+aOHhP4KDaeRkcu2CyvRI= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 5DDEB116807; Tue, 8 Oct 2013 07:34:03 -0400 (EDT) Message-Id: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> X-Sasl-Enc: OIUlkXUi50d5+KkzJpwApFJWztWlvHdb9gYBUIdAw7jF 1381232043 From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: References: Subject: Re: Fuse on FreeBSD 9.2 Date: Tue, 08 Oct 2013 06:34:03 -0500 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:34:04 -0000 On Tue, Oct 8, 2013, at 5:21, =C5=81ukasz P wrote: > Hello, >=20 > Please let me know if anyone is up to fix fuse on FreeBSD 9.x ? >=20 > Particularly this bug:=20 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182739 >=20 >=20=20 >=20 > I'm willing to pay for the fix. >=20 >=20=20 I think the "fix" is the new from-scratch fuse module in FreeBSD 10, which in my experience works flawlessly. Perhaps you should instead see if someone is willing to backport that fuse module to 9.x? From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 11:38:20 2013 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 ESMTP id 3610FEA0; Tue, 8 Oct 2013 11:38:20 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A5A02B43; Tue, 8 Oct 2013 11:38:19 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id lf11so3444604vcb.21 for ; Tue, 08 Oct 2013 04:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DtdxaSAVu0oktcCEgkGmYves7yulDyYjpWITeJaXbeU=; b=aUb8m80OAsbIfAHNx6JYjiGQXtJCkU8CFlUw8S0ryyUSdDrqaosHaH70oXm3er8dsA ab/TUk8B4IKMgdn3Sa2z35vBKF51YBEVCq0selTACiFNw1W1HwQb8pg7xY4FPJu10MEN Mi64i7HsxhJ1a20UDCA2HLnMzo0BXVimaXG7M/KrcHkWPFyJ27wcMZ8SPbOqv/yn3lfx NuCsED5JnweHDEJBRvj/TxdU9XvOQoxsyAVulDEkytqbBw1E51r5iZRUkxDV9mQsQn5g ziEPx7IGtVGlaa7JMt/0HQ6OeFBPBnklLafsZ2S4S4xh6ifSvxc3agoBTixQBDUCqftF 4DwQ== MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr685978vcb.5.1381232298597; Tue, 08 Oct 2013 04:38:18 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 8 Oct 2013 04:38:18 -0700 (PDT) In-Reply-To: References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> Date: Tue, 8 Oct 2013 13:38:18 +0200 X-Google-Sender-Auth: HazPPss71MrSAW3kYkcAXl1fkrA Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Kirk McKusick , Alan Cox , Peter Holm , freebsd-fs@freebsd.org, Ivan Voras , freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:38:20 -0000 On Tue, Oct 8, 2013 at 1:32 PM, Davide Italiano wrote: > On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd wrote: >> Hi, >> > > Hi Adrian, > >> Please try it out on a -10 VM with something RAM limited - say, 128mb w/ >> GENERIC. See how it behaves. >> >> I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not >> to break that before releng/10 is cut. >> >> thanks, >> >> > > This is not supposed to hit 10-STABLE, at least not before proper > review. This is the reason why it was proposed on mailing lists. Also, > if you read the patch you'll end up with realizing this should behave > better on low memory environment because it unconditionally cleans 10% > of the cache every time. Previous changes in this area just did the > opposite keeping a lot more of memory around. I hope this makes sense > to you. > > Thanks, > > -- > Davide > > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare Also, right now you can set up a value which indicates the percentage of memory you can reclaim. It's 10% by default, but we can discuss if this could be adjusted to a more reasonable default. Feel free to give your opinion. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 11:43:46 2013 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 ESMTP id 56C54175 for ; Tue, 8 Oct 2013 11:43:46 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 283812BDB for ; Tue, 8 Oct 2013 11:43:45 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 247A521424 for ; Tue, 8 Oct 2013 07:43:41 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 08 Oct 2013 07:43:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=R/QHdMqU+8z/OYWbW19YCF0PdI8=; b=piF MP5s1bzqa02lIV6lSb0DJ5vKIFbrv3gxNrbmijs6r8QccN2GLtFXOIIWnzjdkR7v Kz8FxETasuY/UqDwysyImJ7/LOtx6g+1QodNUJfWB02RtvEfOsV4N0MLDlY2XNec TXmCsrI6wMF68gdG8say57g7+4h4fMT8KzxlK9H0= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 00946116830; Tue, 8 Oct 2013 07:43:40 -0400 (EDT) Message-Id: <1381232620.9689.31395805.749B13AD@webmail.messagingengine.com> X-Sasl-Enc: gjN4i72u4SwbLwo78jSExelV6H7II/LhRQE73YVs6tch 1381232620 From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> Subject: Re: Fuse on FreeBSD 9.2 Date: Tue, 08 Oct 2013 06:43:40 -0500 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:43:46 -0000 On Tue, Oct 8, 2013, at 6:34, Mark Felder wrote: > > I think the "fix" is the new from-scratch fuse module in FreeBSD 10, > which in my experience works flawlessly. Perhaps you should instead see > if someone is willing to backport that fuse module to 9.x? > Well actually the description on the WhatsNew/FreeBSD10 page has me on the fence about whether or not the port and the new module in FreeBSD 10 share the same source. You could diff it to find out. I'm a bit short on time this morning to dig into that. :-) "The FreeBSD port (including the clean-room BSD-licenced reimplementation of the kernel module) was created during 2 summer of code mandates and being revived by gnn recently. The functionality in this commit matches the content of fusefs-kmod port, which doesn't need to be installed anymore for -CURRENT setups." https://wiki.freebsd.org/WhatsNew/FreeBSD10 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 12:13:45 2013 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 ESMTP id EA993F31; Tue, 8 Oct 2013 12:13:45 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (yugo.yamagi.org [84.201.39.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AAAFC2E3A; Tue, 8 Oct 2013 12:13:45 +0000 (UTC) Received: from [212.48.125.109] (helo=lennart.pwag-local.de) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VTWAX-0007Sd-3t; Tue, 08 Oct 2013 14:13:42 +0200 Date: Tue, 8 Oct 2013 14:13:35 +0200 From: Yamagi Burmeister To: admin@3dr.org Subject: Re: Fuse on FreeBSD 9.2 Message-Id: <20131008141335.e27989337786ed608f936656@yamagi.org> In-Reply-To: References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:13:46 -0000 On Tue, 8 Oct 2013 14:08:41 +0200 Łukasz P wrote: > Thank you - I'll give it a try today. > Can you confirm that doing rsync with this fuse version is stable? I'm sorry but I've never even tried rsync on top of a fuse mount. > Can you please tell us which fuse-based file system have you used? Mostly sysutils/fusefs-smbnetfs to access file servers and sometimes sysutils/fusefs-ntfs with Win XP and Win 7 disks. -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 12:16:00 2013 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 ESMTP id 8D50E16D; Tue, 8 Oct 2013 12:16:00 +0000 (UTC) (envelope-from admin@3dr.org) Received: from futurehost.futurehost.pl (futurehost.futurehost.pl [91.200.185.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4AB032E60; Tue, 8 Oct 2013 12:16:00 +0000 (UTC) Received: from afst9.neoplus.adsl.tpnet.pl ([178.42.227.9]:24623 helo=ukaszBright) by futurehost.futurehost.pl with esmtpa (Exim 4.80) (envelope-from ) id 1VTWCk-000O76-Jg; Tue, 08 Oct 2013 14:15:58 +0200 From: =?utf-8?Q?=C5=81ukasz_P?= To: "'Yamagi Burmeister'" References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> <20131008141335.e27989337786ed608f936656@yamagi.org> In-Reply-To: <20131008141335.e27989337786ed608f936656@yamagi.org> Subject: RE: Fuse on FreeBSD 9.2 Date: Tue, 8 Oct 2013 14:15:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhRsQNP9RYerwp8VXlUebUhV02GwJx2j0nAcWR9a0Cvtwr9gIMdGRZmP2cwnA= Content-Language: pl Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:16:00 -0000 Thank you! > -----Original Message----- > From: Yamagi Burmeister [mailto:lists@yamagi.org] > Sent: Tuesday, October 08, 2013 2:14 PM > To: admin@3dr.org > Cc: feld@FreeBSD.org; freebsd-hackers@freebsd.org > Subject: Re: Fuse on FreeBSD 9.2 >=20 >=20 > On Tue, 8 Oct 2013 14:08:41 +0200 > =C5=81ukasz P wrote: >=20 > > Thank you - I'll give it a try today. > > Can you confirm that doing rsync with this fuse version is stable? >=20 > I'm sorry but I've never even tried rsync on top of a fuse mount. >=20 > > Can you please tell us which fuse-based file system have you used? >=20 > Mostly sysutils/fusefs-smbnetfs to access file servers and sometimes > sysutils/fusefs-ntfs with Win XP and Win 7 disks. >=20 > -- > Homepage: www.yamagi.org > XMPP: yamagi@yamagi.org > GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 12:33:41 2013 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 ESMTP id 74CEA789; Tue, 8 Oct 2013 12:33:41 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C86442F8D; Tue, 8 Oct 2013 12:33:40 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id er20so6786599lab.35 for ; Tue, 08 Oct 2013 05:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DUA2yGY/5+wy6YasqGc4w1OpJNwF5W/9+62r9nVWuy8=; b=CGSnMYNzhaa/eMXx8SXvQ+JXCu77z+tbyRr3PkqxuZ369sW5JV3WkoJL/dNyyzMAPH N3MeDKdqIWAPb3u7bw2CIcXLi0ZGq5WzWog6GWVgQg/9CsCgAak02u5SC8XQeMTAbFUI oW02WqYKIpsowUBjjV0XDaN5UDzUS82j2ymw9OTsLRtrYoI6ZktJiby/TzK/Q+VeWvTS c01P2+dS5UyPuY8d41pauX1Z59QfPkRJkJnlC+ir9nubrs21x3jP7ljrUlLb+bsIIbrW tnZGYh0uYW15dNk1xMuuldRIMeeig2Hjt1JZT+7AsLPAgAH6N++yQJUeIs7reRH60xdp Um+A== X-Received: by 10.112.168.3 with SMTP id zs3mr2418289lbb.2.1381235618825; Tue, 08 Oct 2013 05:33:38 -0700 (PDT) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id k6sm30142762lae.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Oct 2013 05:33:38 -0700 (PDT) Message-ID: <5253FBA0.9010502@gmail.com> Date: Tue, 08 Oct 2013 15:33:36 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Devin Teske Subject: Re: ZFS Boot Menu References: <13CA24D6AB415D428143D44749F57D720FC06B52@LTCFISWMSGMB21.FNFIS.com> <52497AB6.4070906@gmail.com> <13CA24D6AB415D428143D44749F57D720FC3747C@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC3747C@LTCFISWMSGMB21.FNFIS.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:33:41 -0000 06.10.2013 08:54, Teske, Devin wrote: > > On Sep 30, 2013, at 6:20 AM, Volodymyr Kostyrko wrote: > >> 29.09.2013 00:30, Teske, Devin wrote: >>> Interested in feedback, but moreover I would like to see who is >>> interested in tackling this with me? I can't do it alone... I at least >>> need testers whom will provide feedback and edge-case testing. >> >> Sign me in, I'm not fluent with forth but testing something new is always fun. >> > > Cool; to start with, do you have a virtual appliance software like VMware or > VirtualBox? Experience with generating ZFS pools in said software? VirtualBox/Qemu, Qemu is able to emulate boot to serial for example. And yes I tried working with ZFS in VMs. > I think that we may have something to test next month. > > Right now, we're working on the ability of bsdinstall(8) to provision "Boot on > ZFS" as a built-in functionality. That sounds cool. -- Sphinx of black quartz, judge my vow. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 12:38:43 2013 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 ESMTP id 89C5D958 for ; Tue, 8 Oct 2013 12:38:43 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 577D02FCC for ; Tue, 8 Oct 2013 12:38:43 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D3B3A20C64 for ; Tue, 8 Oct 2013 08:38:41 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Tue, 08 Oct 2013 08:38:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=KkhE8vU/7grpo1ZJWM3UnMX2FUk=; b=jZt LDSkUO5MyKYemEoJsBCw1n9+OzpqH7NjACzWCGVvmpeG8e4myEVlAoy8QQj4ckpe PbY7dkG7COhtZpMECl0QKKkQZr3hTWs2TBX3Zde1qdMgsUrTkE9yOodHlLHLwyY9 KJ6ij7Xw+xblQIvatBdBLwTWm3n1vfzH5b+YlN5o= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 77C9C116A0B; Tue, 8 Oct 2013 08:38:41 -0400 (EDT) Message-Id: <1381235921.32469.31415785.22A3256B@webmail.messagingengine.com> X-Sasl-Enc: NH42S81vc6tfJ64syyjXdJ/bw34rd5k5HY4UYm2xA3Kc 1381235921 From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> Subject: Re: Fuse on FreeBSD 9.2 Date: Tue, 08 Oct 2013 07:38:41 -0500 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:38:43 -0000 On Tue, Oct 8, 2013, at 7:08, =C5=81ukasz P wrote: > Thank you - I'll give it a try today. > Can you confirm that doing rsync with this fuse version is stable? >=20 > Can you please tell us which fuse-based file system have you used? >=20 My main use case these days is ntfs-3g, and I no longer get panics when doing mass file operations including rsync. :-) From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 12:41:32 2013 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 ESMTP id B94FDC9D; Tue, 8 Oct 2013 12:41:32 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (yugo.yamagi.org [84.201.39.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7BE802054; Tue, 8 Oct 2013 12:41:31 +0000 (UTC) Received: from [212.48.125.109] (helo=lennart.pwag-local.de) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VTW08-0007MT-QV; Tue, 08 Oct 2013 14:02:58 +0200 Date: Tue, 8 Oct 2013 14:02:51 +0200 From: Yamagi Burmeister To: feld@FreeBSD.org Subject: Re: Fuse on FreeBSD 9.2 Message-Id: <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> In-Reply-To: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, admin@3dr.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:41:32 -0000 There's already a backport which can be found here: http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 1. Download, untar and replace your existing sysutils/fusefs-kmod port with it. Open the Makefile and add "NO_STAGE= yes" to it. 2. cd sysutils/fusefs-kmod ; make makesum ; make deinstall reinstall clean 4. Rebuild sysutils/fusefs-libs and all fuse filesystems (don't know if that's necessary but it doesn't hurt either). I've been running with this kernel module on FreeBSD 9-STABLE, 9.1 and 9.2 four about one year without any problem. I don't know why flo@ never committed his work. On Tue, 08 Oct 2013 06:34:03 -0500 Mark Felder wrote: > On Tue, Oct 8, 2013, at 5:21, Łukasz P wrote: > > Hello, > > > > Please let me know if anyone is up to fix fuse on FreeBSD 9.x ? > > > > Particularly this bug: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=182739 > > > > > > > > I'm willing to pay for the fix. > > > > > > I think the "fix" is the new from-scratch fuse module in FreeBSD 10, > which in my experience works flawlessly. Perhaps you should instead see > if someone is willing to backport that fuse module to 9.x? > _______________________________________________ > 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" -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 12:58:41 2013 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 ESMTP id BCF05594 for ; Tue, 8 Oct 2013 12:58:41 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail1.yamagi.org (yugo.yamagi.org [84.201.39.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7ECD32167 for ; Tue, 8 Oct 2013 12:58:41 +0000 (UTC) Received: from [212.48.125.109] (helo=lennart.pwag-local.de) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VTWs2-0007oz-7S; Tue, 08 Oct 2013 14:58:39 +0200 Date: Tue, 8 Oct 2013 14:58:32 +0200 From: Yamagi Burmeister To: admin@3dr.org Subject: Re: Fuse on FreeBSD 9.2 Message-Id: <20131008145832.537e165859617ab8952e65a2@yamagi.org> In-Reply-To: <20131008141335.e27989337786ed608f936656@yamagi.org> References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> <20131008141335.e27989337786ed608f936656@yamagi.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:58:41 -0000 Responding to myself... On Tue, 8 Oct 2013 14:13:35 +0200 Yamagi Burmeister wrote: > > On Tue, 8 Oct 2013 14:08:41 +0200 > Łukasz P wrote: > > > Thank you - I'll give it a try today. > > Can you confirm that doing rsync with this fuse version is stable? > > I'm sorry but I've never even tried rsync on top of a fuse mount. I've just rsynced ~25GB data from an smbnetfs mount to zfs and back to the smbnetfs mount. No problems so far. That's of course only a first test but apparently there are no obvious problems / panics. -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 13:04:45 2013 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 ESMTP id 7BEBC8A8 for ; Tue, 8 Oct 2013 13:04:45 +0000 (UTC) (envelope-from admin@3dr.org) Received: from futurehost.futurehost.pl (futurehost.futurehost.pl [91.200.185.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3948621ED for ; Tue, 8 Oct 2013 13:04:44 +0000 (UTC) Received: from afst9.neoplus.adsl.tpnet.pl ([178.42.227.9]:11724 helo=ukaszBright) by futurehost.futurehost.pl with esmtpa (Exim 4.80) (envelope-from ) id 1VTWxv-000MyZ-8Y; Tue, 08 Oct 2013 15:04:43 +0200 From: =?utf-8?Q?=C5=81ukasz_P?= To: "'Yamagi Burmeister'" References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> <20131008141335.e27989337786ed608f936656@yamagi.org> <20131008145832.537e165859617ab8952e65a2@yamagi.org> In-Reply-To: <20131008145832.537e165859617ab8952e65a2@yamagi.org> Subject: RE: Fuse on FreeBSD 9.2 Date: Tue, 8 Oct 2013 15:04:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhRsQNP9RYerwp8VXlUebUhV02GwJx2j0nAcWR9a0Cvtwr9gIMdGRZAmYOHLmY6nlfcA== Content-Language: pl Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 13:04:45 -0000 Sounds good - I'm using MooseFS file system - and problems with fuse = occurs during rsync. I will test suggested by you = http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 - and will let know = if that works in few hours. > -----Original Message----- > From: Yamagi Burmeister [mailto:lists@yamagi.org] > Sent: Tuesday, October 08, 2013 2:59 PM > To: admin@3dr.org > Cc: freebsd-hackers@freebsd.org > Subject: Re: Fuse on FreeBSD 9.2 >=20 > Responding to myself... >=20 > On Tue, 8 Oct 2013 14:13:35 +0200 > Yamagi Burmeister wrote: >=20 > > > > On Tue, 8 Oct 2013 14:08:41 +0200 > > =C5=81ukasz P wrote: > > > > > Thank you - I'll give it a try today. > > > Can you confirm that doing rsync with this fuse version is stable? > > > > I'm sorry but I've never even tried rsync on top of a fuse mount. >=20 > I've just rsynced ~25GB data from an smbnetfs mount to zfs and back to = the > smbnetfs mount. No problems so far. That's of course only a first test = but > apparently there are no obvious problems / panics. > -- > Homepage: www.yamagi.org > XMPP: yamagi@yamagi.org > GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 12:08:46 2013 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 ESMTP id F3809D8F; Tue, 8 Oct 2013 12:08:45 +0000 (UTC) (envelope-from admin@3dr.org) Received: from futurehost.futurehost.pl (futurehost.futurehost.pl [91.200.185.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1D082DC9; Tue, 8 Oct 2013 12:08:45 +0000 (UTC) Received: from afst9.neoplus.adsl.tpnet.pl ([178.42.227.9]:23436 helo=ukaszBright) by futurehost.futurehost.pl with esmtpa (Exim 4.80) (envelope-from ) id 1VTW5i-000Dcg-Sy; Tue, 08 Oct 2013 14:08:42 +0200 From: =?utf-8?Q?=C5=81ukasz_P?= To: "'Yamagi Burmeister'" , References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> In-Reply-To: <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> Subject: RE: Fuse on FreeBSD 9.2 Date: Tue, 8 Oct 2013 14:08:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhRsQNP9RYerwp8VXlUebUhV02GwJx2j0nAcWR9a2ZI/Tr8A== Content-Language: pl X-Mailman-Approved-At: Tue, 08 Oct 2013 13:58:30 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:08:46 -0000 Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? Can you please tell us which fuse-based file system have you used? Luke > -----Original Message----- > From: Yamagi Burmeister [mailto:lists@yamagi.org] > Sent: Tuesday, October 08, 2013 2:03 PM > To: feld@FreeBSD.org > Cc: freebsd-hackers@freebsd.org; admin@3dr.org > Subject: Re: Fuse on FreeBSD 9.2 >=20 > There's already a backport which can be found here: > http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 >=20 > 1. Download, untar and replace your existing sysutils/fusefs-kmod > port with it. Open the Makefile and add "NO_STAGE=3D yes" to it. > 2. cd sysutils/fusefs-kmod ; make makesum ; make deinstall reinstall > clean > 4. Rebuild sysutils/fusefs-libs and all fuse filesystems (don't > know if that's necessary but it doesn't hurt either). >=20 > I've been running with this kernel module on FreeBSD 9-STABLE, > 9.1 and 9.2 four about one year without any problem. I don't know why = flo@ > never committed his work. >=20 > On Tue, 08 Oct 2013 06:34:03 -0500 > Mark Felder wrote: >=20 > > On Tue, Oct 8, 2013, at 5:21, =C5=81ukasz P wrote: > > > Hello, > > > > > > Please let me know if anyone is up to fix fuse on FreeBSD 9.x ? > > > > > > Particularly this bug: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182739 > > > > > > > > > > > > I'm willing to pay for the fix. > > > > > > > > > > I think the "fix" is the new from-scratch fuse module in FreeBSD 10, > > which in my experience works flawlessly. Perhaps you should instead > > see if someone is willing to backport that fuse module to 9.x? > > _______________________________________________ > > 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" >=20 > -- > Homepage: www.yamagi.org > XMPP: yamagi@yamagi.org > GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 22:38:11 2013 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 ESMTP id 18A433E7 for ; Tue, 8 Oct 2013 22:38:11 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A591327AD for ; Tue, 8 Oct 2013 22:38:10 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so7921050wes.35 for ; Tue, 08 Oct 2013 15:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=IK8qxveOG4eD/zjxHDHG2xLG3LV1XBTrUXfFumvyChs=; b=eFGKdgqj+TLybgP75oHjjl9k5yJXbdPWd3yKBbgjsGNtaRGe4GgYIAyX1Vc+93nyPf Raxx0jSRjWA+iWP9o3RwTBGJbuab9tY/D+3uzHmFbw+a/XPiag8yNvkUyUxS05QBM0fJ b96YlyDVMGvPY4ECaA8Oeb9TEwGmh2yaM8jvkMttGcmz74oWFDpFa3mPrdI9bJyl2Bdb /6pr974mdESHvomxjYgmqSKYy3UgMqyMlMtqCziVuX8xM/bzsPER+Vc7/tjC6CNvjjSb lMvCkirsTsKqz5Qj02IyI3Qxmx3GrFHWhcyOp1LrlS4eY++WD1Hyb0HfMt11lOTO505f RHIA== X-Received: by 10.194.193.4 with SMTP id hk4mr3850065wjc.29.1381271888641; Tue, 08 Oct 2013 15:38:08 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPSA id k4sm5777120wic.0.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 08 Oct 2013 15:38:08 -0700 (PDT) Date: Tue, 8 Oct 2013 23:38:06 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <20131008233806.54bb0483@gumby.homeunix.com> In-Reply-To: References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:38:11 -0000 On Tue, 8 Oct 2013 13:32:58 +0200 Davide Italiano wrote: > On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd > wrote: > > Hi, > > > > Hi Adrian, > > > Please try it out on a -10 VM with something RAM limited - say, > > 128mb w/ GENERIC. See how it behaves. Be aware that any test that doesn't cause vfs.ufs.dirhash_lowmemcount to increment isn't testing the change at all. > This is not supposed to hit 10-STABLE, at least not before proper > review. This is the reason why it was proposed on mailing lists. Also, > if you read the patch you'll end up with realizing this should behave > better on low memory environment because it unconditionally cleans 10% > of the cache every time. The current version deletes anything older than the time limit and if this doesn't reclaim 10% it makes a second pass through the list until the target is met. Your version tries to delete 10% (or whatever) by looping around the list until this is achieved. And if there aren't enough unlocked entries it will loop indefinitely until there are. I hope you know what you are doing because that looks very wrong. The original version looks better to me given that it already tries to free a minimum of 10%. The low-memory handler is called under very low memory conditions when the system is probably thrashing or even on the verge of killing processes. Holding on to entries that haven't been used for a minute seems like a luxury. > Previous changes in this area just did the > opposite keeping a lot more of memory around. I don't believe that's true. Under most circustances the existing scheme free more memory. The only case when yours frees more is when 90% of the entries are locked. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 8 23:01:26 2013 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 ESMTP id BEBF7EC1 for ; Tue, 8 Oct 2013 23:01:26 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c: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 7BC22292A for ; Tue, 8 Oct 2013 23:01:26 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id lh4so1274vcb.9 for ; Tue, 08 Oct 2013 16:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yh5BQDMb1OeZZaHXM9RQqVbHeqyF5+4vb2/t6fi1WBc=; b=dlRoS+h30mDG+smAChyku1wxCKw5Dbhoc/HA4n9EYqfBHVR+0ABBb4RAs8GkVYYcyt vhN3iF7pLXJT+UMoZsAntDd/UGQ5X7cWCAq/ackvZFHhLJZk3r8BJY7zJI8qwlaTDmyk pvh/I9RKLhm1mrUXJbvwyXPnlwwhlSakv3z6fn8tEQNC1UXvmV94bBSCAQMeKbWaOxSS uwL6sSpw9gzbe+eocYYoGlkFE5KNapF5nVDZ4zPPw+Z+Q+JF6kTmgt5X0dD+Mm5NAt1I Vo3sT+avHKGceqaFVHTDvby4x+HVpHuhgUyjlIDfEbRt6vdWjnmri8jZ2xmkF9J6DmMb qfQQ== MIME-Version: 1.0 X-Received: by 10.52.52.137 with SMTP id t9mr2483725vdo.22.1381273285407; Tue, 08 Oct 2013 16:01:25 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 8 Oct 2013 16:01:25 -0700 (PDT) In-Reply-To: <20131008233806.54bb0483@gumby.homeunix.com> References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> <20131008233806.54bb0483@gumby.homeunix.com> Date: Tue, 8 Oct 2013 16:01:25 -0700 X-Google-Sender-Auth: qCAiEZ0ubH3_wnZF8BN_S23LQIY Message-ID: Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? From: Davide Italiano To: RW Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 23:01:26 -0000 On Tue, Oct 8, 2013 at 3:38 PM, RW wrote: > On Tue, 8 Oct 2013 13:32:58 +0200 > Davide Italiano wrote: > >> On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd >> wrote: >> > Hi, >> > >> >> Hi Adrian, >> >> > Please try it out on a -10 VM with something RAM limited - say, >> > 128mb w/ GENERIC. See how it behaves. > > Be aware that any test that doesn't cause vfs.ufs.dirhash_lowmemcount > to increment isn't testing the change at all. > > >> This is not supposed to hit 10-STABLE, at least not before proper >> review. This is the reason why it was proposed on mailing lists. Also, >> if you read the patch you'll end up with realizing this should behave >> better on low memory environment because it unconditionally cleans 10% >> of the cache every time. > > The current version deletes anything older than the time limit and if > this doesn't reclaim 10% it makes a second pass through the list until > the target is met. > > Your version tries to delete 10% (or whatever) by looping around the > list until this is achieved. And if there aren't enough unlocked > entries it will loop indefinitely until there are. I hope you know > what you are doing because that looks very wrong. > Hi (RW..?), This could be probably changed -- from what | see even under high memory pressure this wasn't a problem but all in all I agree with you that we shouldn't loop forever but limit the number of pass on the list to a somewhat constant number, to prevent pathological cases. > The original version looks better to me given that it already tries to > free a minimum of 10%. The low-memory handler is called under very low > memory conditions when the system is probably thrashing or even on the > verge of killing processes. Holding on to entries that haven't been > used for a minute seems like a luxury. > >> Previous changes in this area just did the >> opposite keeping a lot more of memory around. > > I don't believe that's true. Under most circustances the existing > scheme free more memory. The only case when yours frees more is when 90% > of the entries are locked. Well, no. Here you can set the threshold to a more aggressive value so that you reclaim more memory every time. Note that this was not possible in the previous version, so, if you could have a situation where all your cache entries were not touched for 15 or even 30 seconds they would have kept around, and you can destroy up to 10% of them everytime lowmem event is called. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 08:56:19 2013 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 ESMTP id 7E564466 for ; Wed, 9 Oct 2013 08:56:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CB9FE25FA for ; Wed, 9 Oct 2013 08:56:18 +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 LAA28342 for ; Wed, 09 Oct 2013 11:56:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VTpYw-000OZn-CE for freebsd-hackers@FreeBSD.org; Wed, 09 Oct 2013 11:56:10 +0300 Message-ID: <525519F1.3050703@FreeBSD.org> Date: Wed, 09 Oct 2013 11:55:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: taskqueue_drain_all X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 08:56:19 -0000 I would like to propose to extend taskqueue API with taskqueue_drain_all. A potential use case: I have a private taskqueue, several kinds of tasks get executed via it and then I want to make sure that all of them are completed. Obviously, I have a way to ensure that no new ones get enqueued. Is this a good addition? Or should like consider looping over all of my tasks externally to taskqueue implementation? A quick prototype: --- a/sys/kern/subr_taskqueue.c +++ b/sys/kern/subr_taskqueue.c @@ -316,6 +316,7 @@ taskqueue_run_locked(struct taskqueue *queue) wakeup(task); } TAILQ_REMOVE(&queue->tq_active, &tb, tb_link); + wakeup(&queue->tq_active); } void @@ -402,6 +403,22 @@ taskqueue_drain(struct taskqueue *queue, struct task *task) } void +taskqueue_drain_all(struct taskqueue *queue) +{ + struct task *task; + + TQ_LOCK(queue); + while ((task = STAILQ_FIRST(&queue->tq_queue)) != NULL) { + while (task->ta_pending != 0 || task_is_running(queue, task)) + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + } + while (TAILQ_FIRST(&queue->tq_active) != NULL) + TQ_SLEEP(queue, &queue->tq_active, + &queue->tq_mutex, PWAIT, "-", 0); + TQ_UNLOCK(queue); +} + +void taskqueue_drain_timeout(struct taskqueue *queue, struct timeout_task *timeout_task) { -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 11:34:41 2013 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 ESMTP id 3E3C6F5E for ; Wed, 9 Oct 2013 11:34:41 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C38752F2A for ; Wed, 9 Oct 2013 11:34:39 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3E62E153437; Wed, 9 Oct 2013 13:34:29 +0200 (CEST) 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 pRD2U6NAsVJV; Wed, 9 Oct 2013 13:34:27 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:d4e4:a82d:5c79:81ac] (unknown [IPv6:2001:4cb8:3:1:d4e4:a82d:5c79:81ac]) by smtp.digiware.nl (Postfix) with ESMTP id 70BEC153434; Wed, 9 Oct 2013 13:34:27 +0200 (CEST) Message-ID: <52553F3F.9090707@digiware.nl> Date: Wed, 09 Oct 2013 13:34:23 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com Subject: Re: amdtemp need help with testing References: <52520d5f.c402cd0a.5f4e.ffffffa2@mx.google.com> In-Reply-To: <52520d5f.c402cd0a.5f4e.ffffffa2@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:34:41 -0000 On 2013-10-07 3:24, rozhuk.im@gmail.com wrote: > I updated amdtemp and now I need your help with testing. > > Now the driver should support all AMD processors. > For a family of 15h and 16h, not all sensors are available - for my system > does not find drivers for ati SMBus, and other systems based on the AMD I > have not. CPU: AMD Phenom(tm) II X6 1075T Processor (3013.83-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100fa0 Family = 0x10 Model = 0xa Stepping = 0 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant, performance statistics L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative This is what I get with the 10.0-ALPHA4 driver. sysctl -a | grep amd machine amd64 hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 58.0C This is what I get when I try to compile the new module: freetest# cd /usr/src/sys/modules/amdtemp/ freetest# make Warning: Object directory not changed from original /usr/src/sys/modules/amdtemp cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c:453:9: error: implicit declaration of function 'pci_cfgregread' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if ((pci_cfgregread(pci_get_bus(dev), pci_get_slot(dev), 2, ^ 1 error generated. *** Error code 1 Stop. make: stopped in /usr/src/sys/modules/amdtemp FreeBSD freetest.digiware.nl 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1 r256062: Tue Oct 8 11:05:54 CEST 2013 root@freetest.digiware.nl:/usr/obj/usr/src/sys/FREETEST amd64 --WjW From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 11:42:30 2013 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 ESMTP id 2ACF239B for ; Wed, 9 Oct 2013 11:42:30 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACA042FA9 for ; Wed, 9 Oct 2013 11:42:29 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id o14so649989lbi.18 for ; Wed, 09 Oct 2013 04:42:27 -0700 (PDT) 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=DQQdE9vKTZGi3H3ldxEqVSpOJsc/H5x/Rnc+n3r6UWE=; b=qq1yZiKbgvHgQqJp8aPMVQMOoJrSHF/tMK7jYHDXd86/zco3BYZ1e2vC+/dkt8HlKi xDA9jYjJ+6gbWWfX5Y/Vovz4m5GO3gvnTHJ/3DmvbRR0Y/mdrUfAPylhwu7GU4UCY7hA pzvaOCSrIuMgIRs1vYJPu8Rcu2L/2lBQgKCIz5A0OOrbFpnM3+hRB8FJQw0TIaRpRnf6 uwBi25lSHHNKpgwTNX66B7/+j35Vp2bQjAF3DBdrYUlWyxJU+JldY7kyLCwejWRK5RnW EzzE6xXd3zKMaYRG7XyuQzBfj00yyK4iyt/TJJmpUJp8e4nYGvDmHl4vjNSL34dOuhJH swtg== X-Received: by 10.152.170.166 with SMTP id an6mr6037817lac.20.1381318947662; Wed, 09 Oct 2013 04:42:27 -0700 (PDT) Received: from dhcp174-208-red.yandex.net (dhcp174-208-red.yandex.net. [95.108.174.208]) by mx.google.com with ESMTPSA id i3sm34759886laf.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 04:42:26 -0700 (PDT) From: Dmitry Sivachenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: mmap() question Message-Id: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> Date: Wed, 9 Oct 2013 15:42:27 +0400 To: "hackers@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 09 Oct 2013 12:07:19 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:42:30 -0000 Hello! I have a program which mmap()s a lot of large files (total size more = that RAM and I have no swap), but it needs only small parts of that = files at a time. My understanding is that when using mmap when I access some memory = region OS reads the relevant portion of that file from disk and caches = the result in memory. If there is no free memory, OS will purge = previously read part of mmap'ed file to free memory for the new chunk. But this is not the case. I use the following simple program which gets = list of files as command line arguments, mmap()s them all and then = selects random file and random 1K parts of that file and computes a XOR = of bytes from that region. After some time the program dies: pid 63251 (a.out), uid 1232, was killed: out of swap space It seems I incorrectly understand how mmap() works, can you please = clarify what's going wrong? I expect that program to run indefinitely, purging some regions out of = RAM and reading the relevant parts of files. Thanks! #include #include #include #include #include #include #include #include #include struct f_data { char *beg; off_t size; }; int main(int argc, char* argv[]) { if (argc < 2) { fprintf(stderr, "Usage: %s ...\n", argv[0]); exit(0); } int i, j, fd; struct stat st; struct f_data FILES[500]; int NUM_FILES; void *p; NUM_FILES =3D argc - 1; for (i=3D1; i < argc; i++) { printf("%s... ", argv[i]); if ((fd =3D open(argv[i], O_RDONLY)) < 0) errx(1, "open"); if (fstat(fd, &st) !=3D 0) errx(1, "fstat"); if ((p =3D mmap(NULL, st.st_size, PROT_READ, MAP_NOCORE, fd, 0)) = =3D=3D MAP_FAILED) errx(1, "mmap"); FILES[i-1].beg =3D (char*)p; FILES[i-1].size =3D st.st_size; if (msync(p, st.st_size, MS_INVALIDATE) !=3D 0) errx(1, "msync"); printf("Ok.\n"); } char chk =3D 0; while(1) { int rf =3D floor((double)random() / 2147483647 * NUM_FILES); off_t offs =3D floor((double)random() / 2147483647 * = (FILES[rf].size - 1024)); for (j=3D0; j<1024; j++) chk ^=3D *(FILES[rf].beg + offs + j); } return 0; } From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 12:09:55 2013 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 ESMTP id 9DC06316 for ; Wed, 9 Oct 2013 12:09:55 +0000 (UTC) (envelope-from wjw@digiware.nl) 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 43ED321B9 for ; Wed, 9 Oct 2013 12:09:55 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 1BF89153437; Wed, 9 Oct 2013 14:09:53 +0200 (CEST) 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 Gd-YVbXUngP2; Wed, 9 Oct 2013 14:09:51 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:d4e4:a82d:5c79:81ac] (unknown [IPv6:2001:4cb8:3:1:d4e4:a82d:5c79:81ac]) by smtp.digiware.nl (Postfix) with ESMTP id 4BE40153434; Wed, 9 Oct 2013 14:09:51 +0200 (CEST) Message-ID: <5255478B.9090305@digiware.nl> Date: Wed, 09 Oct 2013 14:09:47 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com Subject: Re: amdtemp need help with testing References: <52520d5f.c402cd0a.5f4e.ffffffa2@mx.google.com> <52553F3F.9090707@digiware.nl> In-Reply-To: <52553F3F.9090707@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 12:09:55 -0000 On 2013-10-09 13:34, Willem Jan Withagen wrote: > On 2013-10-07 3:24, rozhuk.im@gmail.com wrote: >> I updated amdtemp and now I need your help with testing. >> >> Now the driver should support all AMD processors. >> For a family of 15h and 16h, not all sensors are available - for my >> system >> does not find drivers for ati SMBus, and other systems based on the AMD I >> have not. > > CPU: AMD Phenom(tm) II X6 1075T Processor (3013.83-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100fa0 Family = 0x10 Model = 0xa > Stepping = 0 > Features=0x178bfbff > > Features2=0x802009 > AMD > Features=0xee500800 > AMD > Features2=0x37ff > > TSC: P-state invariant, performance statistics > L1 2MB data TLB: 48 entries, fully associative > L1 2MB instruction TLB: 16 entries, fully associative > L1 4KB data TLB: 48 entries, fully associative > L1 4KB instruction TLB: 32 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way > associative > L2 2MB data TLB: 128 entries, 2-way associative > L2 2MB instruction TLB: 0 entries, 2-way associative > > This is what I get with the 10.0-ALPHA4 driver. > > sysctl -a | grep amd > machine amd64 > hw.machine: amd64 > hw.machine_arch: amd64 > hw.snd.version: 2009061500/amd64 > hw.mca.amd10h_L1TP: 1 > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors > dev.amdtemp.0.%driver: amdtemp > dev.amdtemp.0.%parent: hostb4 > dev.amdtemp.0.sensor_offset: 0 > dev.amdtemp.0.core0.sensor0: 58.0C > After bruteforce fixing the compile error by deleting the #ifdef around the definition... --WjW freetest# sysctl -a | grep amd machine amd64 "Giant","amdtemp" hw.machine: amd64 hw.machine_arch: amd64 hw.snd.version: 2009061500/amd64 hw.mca.amd10h_L1TP: 1 dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.rtc.CurTmp: 36.6C dev.amdtemp.0.rtc.CurTmpTjSel: -12.5C dev.amdtemp.0.rtc.TmpSlewDnEn: 1 dev.amdtemp.0.rtc.TmpMaxDiffUp: 3 dev.amdtemp.0.rtc.PerStepTimeDn: 15 dev.amdtemp.0.rtc.PerStepTimeUp: 15 dev.amdtemp.0.rtc.sensor_offset: 0 dev.amdtemp.0.tsi.sensor0.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor0.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor0.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor0.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor0.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor0.status: 0 dev.amdtemp.0.tsi.sensor0.cfg3: 0 dev.amdtemp.0.tsi.sensor0.cfg9: 0 dev.amdtemp.0.tsi.sensor0.upd_rate: 8 dev.amdtemp.0.tsi.sensor0.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor0.alert_threshold: 0 dev.amdtemp.0.tsi.sensor0.alert_cfg: 0 dev.amdtemp.0.tsi.sensor0.manufacture_id: 0 dev.amdtemp.0.tsi.sensor0.revision: 1 dev.amdtemp.0.tsi.sensor0.sensor_offset: 0 dev.amdtemp.0.tsi.sensor1.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor1.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor1.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor1.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor1.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor1.status: 0 dev.amdtemp.0.tsi.sensor1.cfg3: 0 dev.amdtemp.0.tsi.sensor1.cfg9: 0 dev.amdtemp.0.tsi.sensor1.upd_rate: 8 dev.amdtemp.0.tsi.sensor1.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor1.alert_threshold: 0 dev.amdtemp.0.tsi.sensor1.alert_cfg: 0 dev.amdtemp.0.tsi.sensor1.manufacture_id: 0 dev.amdtemp.0.tsi.sensor1.revision: 1 dev.amdtemp.0.tsi.sensor1.sensor_offset: 0 dev.amdtemp.0.tsi.sensor2.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor2.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor2.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor2.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor2.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor2.status: 0 dev.amdtemp.0.tsi.sensor2.cfg3: 0 dev.amdtemp.0.tsi.sensor2.cfg9: 0 dev.amdtemp.0.tsi.sensor2.upd_rate: 8 dev.amdtemp.0.tsi.sensor2.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor2.alert_threshold: 0 dev.amdtemp.0.tsi.sensor2.alert_cfg: 0 dev.amdtemp.0.tsi.sensor2.manufacture_id: 0 dev.amdtemp.0.tsi.sensor2.revision: 1 dev.amdtemp.0.tsi.sensor2.sensor_offset: 0 dev.amdtemp.0.tsi.sensor3.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor3.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor3.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor3.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor3.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor3.status: 0 dev.amdtemp.0.tsi.sensor3.cfg3: 0 dev.amdtemp.0.tsi.sensor3.cfg9: 0 dev.amdtemp.0.tsi.sensor3.upd_rate: 8 dev.amdtemp.0.tsi.sensor3.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor3.alert_threshold: 0 dev.amdtemp.0.tsi.sensor3.alert_cfg: 0 dev.amdtemp.0.tsi.sensor3.manufacture_id: 0 dev.amdtemp.0.tsi.sensor3.revision: 1 dev.amdtemp.0.tsi.sensor3.sensor_offset: 0 dev.amdtemp.0.tsi.sensor4.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor4.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor4.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor4.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor4.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor4.status: 0 dev.amdtemp.0.tsi.sensor4.cfg3: 0 dev.amdtemp.0.tsi.sensor4.cfg9: 0 dev.amdtemp.0.tsi.sensor4.upd_rate: 8 dev.amdtemp.0.tsi.sensor4.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor4.alert_threshold: 0 dev.amdtemp.0.tsi.sensor4.alert_cfg: 0 dev.amdtemp.0.tsi.sensor4.manufacture_id: 0 dev.amdtemp.0.tsi.sensor4.revision: 1 dev.amdtemp.0.tsi.sensor4.sensor_offset: 0 dev.amdtemp.0.tsi.sensor5.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor5.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor5.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor5.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor5.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor5.status: 0 dev.amdtemp.0.tsi.sensor5.cfg3: 0 dev.amdtemp.0.tsi.sensor5.cfg9: 0 dev.amdtemp.0.tsi.sensor5.upd_rate: 8 dev.amdtemp.0.tsi.sensor5.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor5.alert_threshold: 0 dev.amdtemp.0.tsi.sensor5.alert_cfg: 0 dev.amdtemp.0.tsi.sensor5.manufacture_id: 0 dev.amdtemp.0.tsi.sensor5.revision: 1 dev.amdtemp.0.tsi.sensor5.sensor_offset: 0 dev.amdtemp.0.tsi.sensor6.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor6.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor6.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor6.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor6.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor6.status: 0 dev.amdtemp.0.tsi.sensor6.cfg3: 0 dev.amdtemp.0.tsi.sensor6.cfg9: 0 dev.amdtemp.0.tsi.sensor6.upd_rate: 8 dev.amdtemp.0.tsi.sensor6.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor6.alert_threshold: 0 dev.amdtemp.0.tsi.sensor6.alert_cfg: 0 dev.amdtemp.0.tsi.sensor6.manufacture_id: 0 dev.amdtemp.0.tsi.sensor6.revision: 1 dev.amdtemp.0.tsi.sensor6.sensor_offset: 0 dev.amdtemp.0.tsi.sensor7.cpu_temperature: 36.6C dev.amdtemp.0.tsi.sensor7.high_temperature_threshold: 70.0C dev.amdtemp.0.tsi.sensor7.low_temperature_threshold: 0.0C dev.amdtemp.0.tsi.sensor7.cpu_temperature_offset_hi: 0 dev.amdtemp.0.tsi.sensor7.cpu_temperature_offset_lo: 0 dev.amdtemp.0.tsi.sensor7.status: 0 dev.amdtemp.0.tsi.sensor7.cfg3: 0 dev.amdtemp.0.tsi.sensor7.cfg9: 0 dev.amdtemp.0.tsi.sensor7.upd_rate: 8 dev.amdtemp.0.tsi.sensor7.timeout_cfg: 128 dev.amdtemp.0.tsi.sensor7.alert_threshold: 0 dev.amdtemp.0.tsi.sensor7.alert_cfg: 0 dev.amdtemp.0.tsi.sensor7.manufacture_id: 0 dev.amdtemp.0.tsi.sensor7.revision: 1 dev.amdtemp.0.tsi.sensor7.sensor_offset: 0 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 12:59:34 2013 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 ESMTP id 87FE86A1 for ; Wed, 9 Oct 2013 12:59:34 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16CF324C1 for ; Wed, 9 Oct 2013 12:59:33 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id q58so877268wes.17 for ; Wed, 09 Oct 2013 05:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=wccFRot738vIN1ub3HwdWyI/BK++nHUdXjlg8POuSVc=; b=Guev8lB/nXLMjYiYBlGsXFD+XlycpEvKHro+DFIIAVStFr03PC41Sxd7yCBScvSD1T e9kz5IEosabvZnvY8/cFFCAxvyXsVcOSVKyDu+5pvLF0NdN3g+F5ZJ1aXrzM48PRj9Mm HvyuhaQ2VmXpjpusszS0nlC51hFhWvK3kh44RGahMnarTL/qMxbjDEjrDp7Zks+wCUIr +bP5zoI32HMKTuVNuNLi93M39IxELHUQc6AaUaaWdZzg2LmkH5S0vpxhj5seRhr7RUZR Qwp/oRH5cnlOtjZPhKXlZK3OEPqxdxymxfkrJrUYVZnLZaTSFkmVOM5QEiZSQ7OZIJHR cEbg== X-Received: by 10.194.118.169 with SMTP id kn9mr986264wjb.71.1381323572413; Wed, 09 Oct 2013 05:59:32 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPSA id gp9sm15073520wib.8.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 05:59:31 -0700 (PDT) Date: Wed, 9 Oct 2013 13:59:28 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <20131009135928.702f1910@gumby.homeunix.com> In-Reply-To: References: <20130828181228.0d3618dd@ernst.home> <201309031507.33098.jhb@freebsd.org> <20131008063433.GA47506@x2.osted.lan> <20131008233806.54bb0483@gumby.homeunix.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 12:59:34 -0000 On Tue, 8 Oct 2013 16:01:25 -0700 Davide Italiano wrote: > This could be probably changed -- from what | see even under high > memory pressure this wasn't a problem but all in all I agree with you > that we shouldn't loop forever but limit the number of pass on the > list to a somewhat constant number, to prevent pathological cases. I don't see any need to loop. > > I don't believe that's true. Under most circustances the existing > > scheme free more memory. The only case when yours frees more is > > when 90% of the entries are locked. > > Well, no. Here you can set the threshold to a more aggressive value so > that you reclaim more memory every time. Note that this was not > possible in the previous version, so, if you could have a situation > where all your cache entries were not touched for 15 or even 30 > seconds they would have kept around, and you can destroy up to 10% of > them everytime lowmem event is called. Outside of contrived stress tests I think it's very rare for a significant fraction of the cache to have been accessed in the last minute - particularly on large caches where this matters most. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 13:45:42 2013 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 ESMTP id A4B9CB4C for ; Wed, 9 Oct 2013 13:45:42 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3C83027B7 for ; Wed, 9 Oct 2013 13:45:42 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id mx11so332374bkb.4 for ; Wed, 09 Oct 2013 06:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=8+6PSDn3P3Wza3oC4+xRcq51v/ZwzfstpmeH5N+zjN0=; b=XtL4AvDHk8FxXAk32aJKqniT0HTHEFziTLF6n4FCIR2tx2YyIjDuqHO8BSedXyqY5H BNyVizaInyy8RgXrdwOzjeGqZD4cOjofwKTv5NQYNQjU1IJLzfo29aanYmDi8OnpL7Rt 4/G2A974pn66f5tGu7vfmYG7N3VMEles9NF1zdaE92XRt8T6miNM8G4XP9H0uW8XpKhR zumMpdIFzZ0GKjpTaj4cftJSN3N4p51uGzoqt7O11QanvxBSRhmiexSLhNlsRqoDFhFx SExMxN30juOK5P7YqD3qHm1Lbfiyyryclhdk8vouukkMn7vZ1NzqPlzVla87bte8kJJs cuQQ== X-Received: by 10.205.14.197 with SMTP id pr5mr7083012bkb.6.1381326340444; Wed, 09 Oct 2013 06:45:40 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPSA id a4sm23896162bko.11.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 06:45:40 -0700 (PDT) Date: Wed, 9 Oct 2013 14:45:37 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: mmap() question Message-ID: <20131009144537.4b1a5eb7@gumby.homeunix.com> In-Reply-To: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 13:45:42 -0000 On Wed, 9 Oct 2013 15:42:27 +0400 Dmitry Sivachenko wrote: > Hello! > > I have a program which mmap()s a lot of large files (total size more > that RAM and I have no swap), but it needs only small parts of that > files at a time. > > My understanding is that when using mmap when I access some memory > region OS reads the relevant portion of that file from disk and > caches the result in memory. If there is no free memory, OS will > purge previously read part of mmap'ed file to free memory for the new > chunk. > >... > > It seems I incorrectly understand how mmap() works, can you please > clarify what's going wrong? > > I expect that program to run indefinitely, purging some regions out > of RAM and reading the relevant parts of files. I think your problem is that you are accessing the memory so rapidly that the pages can't even get out of the active queue. The VM system isn't optimized for this kind of abnormal access. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 13:57:43 2013 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 ESMTP id 279C41E1 for ; Wed, 9 Oct 2013 13:57:43 +0000 (UTC) (envelope-from patrick_dkt@yahoo.com.hk) Received: from nm14-vm3.bullet.mail.sg3.yahoo.com (nm14-vm3.bullet.mail.sg3.yahoo.com [106.10.149.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 85016285C for ; Wed, 9 Oct 2013 13:57:41 +0000 (UTC) Received: from [106.10.166.61] by nm14.bullet.mail.sg3.yahoo.com with NNFMP; 09 Oct 2013 13:55:51 -0000 Received: from [106.10.150.27] by tm18.bullet.mail.sg3.yahoo.com with NNFMP; 09 Oct 2013 13:55:51 -0000 Received: from [127.0.0.1] by omp1028.mail.sg3.yahoo.com with NNFMP; 09 Oct 2013 13:55:51 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 419793.61987.bm@omp1028.mail.sg3.yahoo.com Received: (qmail 69254 invoked by uid 60001); 9 Oct 2013 13:55:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.hk; s=s1024; t=1381326951; bh=x8wrxDtKRNIY88DEHG8kAQHyLo9v49iKIhfymP2/W+I=; 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=e/bbR1q9WExotZlpQNJ7KFyfZ6kJUiOPqdTcpomzPe1EYizWN7/PqRRYpCPB3UKMHZvvqgyQn/lltFS1htqY3VPQ/+am+m+ikLQNLYJku6eNeSpURkWtR2ZUIo1ye94sfQUiVKtbdiipSteMFphghjywtuf+12j4xthtDraVLro= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; 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=YAweAPA0N9wtPBtqb1v1LmvO+lJNlHWedeVvwvzjjpcyZaose92Z0HR0AdUWhmjT3pFaZO3vjreZRGESf5RGTXd0oHBR5MBdkT0aLYU+DyLI/Sn2fLRciRtGNSapW/CsTEvhOnUV+lci+hrCb4/tZ7S84q5HgrA00uDdA6QNAE8=; X-YMail-OSG: xMfh1moVM1kR.ZNn.a258YCfZvOpQ6fGpUQZ0Succrk9pym qnaTId.AExoVtz0AAL7v4zu9M0NPygG2tpZ1y0u__NsuOISJbIjXnN1xSIoD uPDKK59PdQfXeE_t17q.rs81Ob_PH1ZcVSfhXU2ylNPErlLMZeawoTZGrou4 sP_6ZrS21ZQPVFvuffpLH3N6zy9.JlSTZ_wnbdqRrRZ.iP2Y059skG5ayrYx 26_6yfy9akdx3zM94BJ_ZJR6Q5Joa4s0SSr48MIiUj8RIFg4XJJjNns0P0Na RLbD1mjOwKiNbByM68gQ3d6QB9VQ0HDqbkcsSL0BoqL7iCiuKKiKd74PLSOp l3nJypOlkhKCxuYufoA5_aGVJCWdonvHdnYwDLA0cVnYl1Zt.Es_GhfEjgZL P3NG9h4J7HLmakv9_ZVlPdnvabR3.SVEOgZt.5LGR7dRvIYQddW6tvaravMG nXh.7he0qrR.rpUiDagLJhVjGa.rmmSve5gC.VjsWqLpQ5ie3ngrLLLcyBQv n0gFD2b6odtrEJHhn.i0whCtBLeYvlHiQ5Y74eYS58f45Y2Iw_h8Mj8czWxI FjK6Oo9VwrXejzA-- Received: from [61.15.240.133] by web193502.mail.sg3.yahoo.com via HTTP; Wed, 09 Oct 2013 21:55:51 SGT X-Rocket-MIMEInfo: 002.001, SGVsbG8sIAoKCkkgd291bGQgbGlrZSB0byBrbm93IGl0IHRoZXJlIGlzIGR0cmFjZSBzdXBwb3J0IGluIHRoZSBvcGVuamRrNz8KClRoYW5rcywKUGF0cmljayBEdW5nCgoKCgpPbiBUdWVzZGF5LCBPY3RvYmVyIDgsIDIwMTMgMToyNiBQTSwgUGF0cmljayBEdW5nIDxwYXRyaWNrX2RrdEB5YWhvby5jb20uaGs.IHdyb3RlOgogCkhpIGFsbCwKCkkgd291bGQgbGlrZSB0byBrbm93IGl0IHRoZXJlIGlzIGR0cmFjZSBzdXBwb3J0IGluIHRoZSBvcGVuamRrNz8KClRoYW5rcywKUGF0cmljawpfX19fX19fX19fX18BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1381209858.81219.YahooMailNeo@web193501.mail.sg3.yahoo.com> Message-ID: <1381326951.68334.YahooMailNeo@web193502.mail.sg3.yahoo.com> Date: Wed, 9 Oct 2013 21:55:51 +0800 (SGT) From: Patrick Dung Subject: Re: openjdk7 dtrace support To: freebsd hackers In-Reply-To: <1381209858.81219.YahooMailNeo@web193501.mail.sg3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Patrick Dung List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 13:57:43 -0000 Hello, I would like to know it there is dtrace support in the openjdk7? Thanks, Patrick Dung On Tuesday, October 8, 2013 1:26 PM, Patrick Dung wrote: Hi all, I would like to know it there is dtrace support in the openjdk7? Thanks, Patrick _______________________________________________ freebsd-java@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-java To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 15:14:45 2013 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 ESMTP id AF796F82; Wed, 9 Oct 2013 15:14:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F65B2E27; Wed, 9 Oct 2013 15:14:45 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id n9so680144qcw.33 for ; Wed, 09 Oct 2013 08:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+eNsbE1NRFViz/zO8E1B3OUoNCt2PqOv23P24xczCfM=; b=hXx2KqSOu92S+tZ6p9mYvPncMx9lS0jc7N8nHf1zKGW9VbH24U0OyaIgMTFYAe6Poc 4MLzBNB8Pg10EhpsLWTZwTHcN116HJq0CjtGdwTdMTXfkMvXZVWRZ+UDkjE/lMLXIFQ0 IZJqTnQIcRHTfTILG+o4rsmKbvd99ICb42tI/YAgx0/n+F0nY0ds4oDRNQn574J1dhAJ SL+c0qqcOvPQRjlluMv3v69h8uKEeSyajMiMBVVGv/n/w9qKpTfRc3sHFMYourXy2SDm xx8rXFzxD36/dWfDHB6lUlmQ91NAz5iqfTiyAHM7YwG5Iltd8gQaU4feROF1Hr99XxvV nUzQ== MIME-Version: 1.0 X-Received: by 10.49.59.115 with SMTP id y19mr10271335qeq.8.1381331659464; Wed, 09 Oct 2013 08:14:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Wed, 9 Oct 2013 08:14:19 -0700 (PDT) In-Reply-To: <525519F1.3050703@FreeBSD.org> References: <525519F1.3050703@FreeBSD.org> Date: Wed, 9 Oct 2013 08:14:19 -0700 X-Google-Sender-Auth: mRCdePu_EJtS8i1PFcXjjdm33Gk Message-ID: Subject: Re: taskqueue_drain_all From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:14:45 -0000 +1 Very useful :) -a On 9 October 2013 01:55, Andriy Gapon wrote: > > I would like to propose to extend taskqueue API with taskqueue_drain_all. > A potential use case: I have a private taskqueue, several kinds of tasks > get > executed via it and then I want to make sure that all of them are > completed. > Obviously, I have a way to ensure that no new ones get enqueued. > > Is this a good addition? > Or should like consider looping over all of my tasks externally to > taskqueue > implementation? > > A quick prototype: > > --- a/sys/kern/subr_taskqueue.c > +++ b/sys/kern/subr_taskqueue.c > @@ -316,6 +316,7 @@ taskqueue_run_locked(struct taskqueue *queue) > wakeup(task); > } > TAILQ_REMOVE(&queue->tq_active, &tb, tb_link); > + wakeup(&queue->tq_active); > } > > void > @@ -402,6 +403,22 @@ taskqueue_drain(struct taskqueue *queue, struct task > *task) > } > > void > +taskqueue_drain_all(struct taskqueue *queue) > +{ > + struct task *task; > + > + TQ_LOCK(queue); > + while ((task = STAILQ_FIRST(&queue->tq_queue)) != NULL) { > + while (task->ta_pending != 0 || task_is_running(queue, > task)) > + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, > "-", 0); > + } > + while (TAILQ_FIRST(&queue->tq_active) != NULL) > + TQ_SLEEP(queue, &queue->tq_active, > + &queue->tq_mutex, PWAIT, "-", 0); > + TQ_UNLOCK(queue); > +} > + > +void > taskqueue_drain_timeout(struct taskqueue *queue, > struct timeout_task *timeout_task) > { > > > -- > Andriy Gapon > > _______________________________________________ > 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 Wed Oct 9 19:31:43 2013 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 ESMTP id 3BF9D1A3 for ; Wed, 9 Oct 2013 19:31:43 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id D6A922FB9 for ; Wed, 9 Oct 2013 19:31:42 +0000 (UTC) X-AuditID: 12074425-b7f1c8e0000009c7-8e-5255adeb18c4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8E.43.02503.BEDA5525; Wed, 9 Oct 2013 15:26:35 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r99JQZSt002777; Wed, 9 Oct 2013 15:26:35 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r99JQX4v030281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 15:26:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r99JQWIF028650; Wed, 9 Oct 2013 15:26:32 -0400 (EDT) Date: Wed, 9 Oct 2013 15:26:32 -0400 (EDT) From: Benjamin Kaduk To: Eitan Adler Subject: Re: patch(1) depends on RCS - should it? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrPt6bWiQwZYF1hYbFhRaLDrRzuTA 5DFt80E2jxmf5rMEMEVx2aSk5mSWpRbp2yVwZWw5NIup4CFrxbHJN9kbGI+zdDFyckgImEi8 fdjJDmGLSVy4t56ti5GLQ0hgH6PEn6avTBDOBkaJgxdfMUM4B5kk+u7uZwRpERKol/i94Scz iM0ioCXR0DCJCcRmE1CRmPlmIxuILSKgJvHudTdYPbOAuMTCe71Aqzk4hAUMJQ4uAtvMKRAo 0bTjE1grr4CjxI/955ggxgdI3Jz/BuxSUQEdidX7p7BA1AhKnJz5hAVipKXEuT/X2SYwCs5C kpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRroVebmaJXmpK6SZGUJiyu6juYJxwSOkQ owAHoxIPb0VZaJAQa2JZcWXuIUZJDiYlUd5Fa4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgD u4ByvCmJlVWpRfkwKWkOFiVx3lsc9kFCAumJJanZqakFqUUwWRkODiUJ3jcgQwWLUtNTK9Iy c0oQ0kwcnCDDeYCG/wCp4S0uSMwtzkyHyJ9iVJQS5/0KkhAASWSU5sH1wtLIK0ZxoFeEeRmB SUWIB5iC4LpfAQ1mAhq8/XsIyOCSRISUVANjl7nIL03pw2sWTPzspXHlYH3Gk9Man750JvuJ b+nwkbC1sBF30zIUO1L/RCal9QN3d5gA/4T63j0OsQqn1yUKBL9YJa+VcMZwi7TI5p9tRgrS Yq92aHDysqleE5MKuVKy23mJ7RnLd1nGS44l2zqoLg01PvDY/fYmbadISZ8Eg5TPr4+62Cix FGckGmoxFxUnAgBZ/P8A/gIAAA== Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:31:43 -0000 I guess I'm late to the party (catching up on the whole thread took a while...) On Mon, 7 Oct 2013, Eitan Adler wrote: > patch(1) explicitly tries to use RCS (and SCCS) in certain cases. Are > we okay with a base system utility that behaves differently depending > on whether a port is installed? Should the relevant code be removed > from patch(1)? > > See head/usr.bin/patch/inp.c lines 166 to 240 for details. It seems like maybe this question should have been answered before rcs was removed, instead of after? (I don't know whether I would have expected you to be able to find every use of rcs, everywhere, prior to removing it, but this is what public declaration of intent/discussions help with.) -Ben From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 20:53:28 2013 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 ESMTP id D8705CDB for ; Wed, 9 Oct 2013 20:53:28 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE240250A for ; Wed, 9 Oct 2013 20:53:28 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id p10so1548742pdj.18 for ; Wed, 09 Oct 2013 13:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9Z+M+zdKUUZK1X5UPEgUsCWGEbKB+K4x16/+Lcl5QhA=; b=Z5COq1jBBNdOSAdkLnjJ6ZREhO//0tivt49opBYcUEJiUADLhVi8Dym0DEj+ZX+M/8 3Bdcv/QnhgcovS6l6zR9SsctUlt/5Xqq0LOi9X7lVlcC5b7dBTzxJuLspzXC1UHc1pKB FMgh0ta++oE5gTWtJjE9+ZJAy1ckUSGKbUldY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9Z+M+zdKUUZK1X5UPEgUsCWGEbKB+K4x16/+Lcl5QhA=; b=nOH7RgpfkP/ChNvrPz3srUE9xboAzphtHoPjvTGzoMzdYYFSdjb9bAb2Sf6S43iNvZ Unm6WyVVwHyPUsQQKKcB/KEZ2QDDii7QXxXQFlDRumB9USRI6J7mFlMJK8uwFk5OfuTg jbnFRLyyWATSOFccU3bck+y/ed5IYTIBXgCpGQAKjeSgpdpkaNsrDqkVClqXVlUh1o1O wSiNXE68PZn5cUKUjgzRQtU1+qcflnDSdCceHhZ6nGp0HXoGq5OV6gAu4b6YIxd+zu0d BuuOjwYiGxRVzRb8A1wQ0MKeXD4SM1oRyIZP+vxOKoeYp24+eQ7RQCpEB3lT9Q/GhUN+ Ikzg== X-Gm-Message-State: ALoCoQlarMsurM4YAtUWDC586eRczU6z91ZNjivcAgc5440dZiPPmbh0On3vb+KUzYvzLIj1pp0H X-Received: by 10.68.234.73 with SMTP id uc9mr9856026pbc.142.1381352007844; Wed, 09 Oct 2013 13:53:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.6.3 with HTTP; Wed, 9 Oct 2013 13:52:57 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Wed, 9 Oct 2013 16:52:57 -0400 Message-ID: Subject: Re: patch(1) depends on RCS - should it? To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:53:28 -0000 On Wed, Oct 9, 2013 at 3:26 PM, Benjamin Kaduk wrote: > I guess I'm late to the party (catching up on the whole thread took a > while...) > > > On Mon, 7 Oct 2013, Eitan Adler wrote: > >> patch(1) explicitly tries to use RCS (and SCCS) in certain cases. Are >> we okay with a base system utility that behaves differently depending >> on whether a port is installed? Should the relevant code be removed >> from patch(1)? >> >> See head/usr.bin/patch/inp.c lines 166 to 240 for details. > > > It seems like maybe this question should have been answered before rcs was > removed, instead of after? > (I don't know whether I would have expected you to be able to find every use > of rcs, everywhere, prior to removing it, but this is what public > declaration of intent/discussions help with.) I was asked by members of core@ to expedite the removal to 10.X - it was not done just because I felt like it. In any case its been reverted now so the discussion is moot. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 9 21:57:35 2013 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 ESMTP id 3450679E; Wed, 9 Oct 2013 21:57:35 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 762502964; Wed, 9 Oct 2013 21:57:34 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/auYssSp3lv7r2GKSMw== X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-2-207-184-39.web.vodafone.de [2.207.184.39]) by smtp.strato.de (RZmta 32.6 DYNA|AUTH) with (TLSv1.0:DHE-RSA-AES256-SHA encrypted) ESMTPSA id t014cep99JgPBC ; Wed, 9 Oct 2013 23:57:19 +0200 (CEST) Received: by britannica.bec.de (sSMTP sendmail emulation); Wed, 09 Oct 2013 23:57:18 +0200 Date: Wed, 9 Oct 2013 23:57:18 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: patch(1) depends on RCS - should it? Message-ID: <20131009215718.GA26158@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:57:35 -0000 On Mon, Oct 07, 2013 at 04:17:03PM -0400, Eitan Adler wrote: > patch(1) explicitly tries to use RCS (and SCCS) in certain cases. At the SCCS behavior is part of (the SCCS option in ) POSIX 2008. So far I haven't seen any reason for messing with it. Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 10 00:04:37 2013 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 ESMTP id 49CF3FC2 for ; Thu, 10 Oct 2013 00:04:37 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 271852FF9 for ; Thu, 10 Oct 2013 00:04:37 +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 D7F731A3C6F for ; Wed, 9 Oct 2013 17:04:36 -0700 (PDT) Message-ID: <5255EF1A.7070305@mu.org> Date: Wed, 09 Oct 2013 17:04:42 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: hackers@freebsd.org Subject: git session at BAFUG tomorrow (San Francisco Bay Area FreeBSD User Group). Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 00:04:37 -0000 I've been doing a few one-on-one sessions at iXsystems explaining the git model to developers and have had much success. Tomorrow at BAFUG (http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/144351492/) I will be doing a quick talk on git and then doing a breakaway session on managing large projects using git. > This week Alfred Perlstein will have a GIT talk for FreeBSD users, and > offer a 1-2 hour demo in a break awayfor people interested in doing a > hands-on GIT experience managing a large project. > > We will cover migration of your FreeBSD customizations based on one > version of FreeBSD to another FreeBSD version. Specifically, Alfred > will be doing a hands-on using "rebasing", to do this migration. > > To participate, all that needs to be done is to have run "git clone > https://github.com/freebsd/freebsd" beforehand (as this takes about 30 > minutes). > > In addition, a computer with wi-fi or some internet connection to > github.com is needed. > > As a prerequisite, it is expected that you have some understanding of > "patch(1)" and "diff(1)". > > There will be no recording allowed and the format will allow only for > short discussion and no derailing. Discussion of other SCM tools is > only appropriate in the context of understanding what we are doing in > git. Advocacy of other SCM tools will not be tolerated. If you can > not abide by these rules you will be asked to leave the session. > > The workshop will mostly focus on "git rebase" of a large project, however we may cover a few other areas depending on how much progress we make in the 1-2 hours we set aside. Again, if you want to participate, show up on time and make sure you have a git clone of freebsd already made! -Alfred -- Alfred Perlstein From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 10 04:07:46 2013 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 ESMTP id 87A5F7ED for ; Thu, 10 Oct 2013 04:07:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 567232B6D for ; Thu, 10 Oct 2013 04:07:46 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id x13so4038852ief.29 for ; Wed, 09 Oct 2013 21:07:45 -0700 (PDT) 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=2E3Dpt+u2ueHRMh5/8ktw/I4wqJPcHQNMgkZNG9tuo4=; b=HadRf1oPPY1skU619RyhepVnyemL9anRuzGWzMMV07BLCdKbTIkTdqceJN6dkZ7JR1 ezpEoN/bS7ZoAWeiEpyWllBxOChQbHgFvEiAvPkReZCHIgkS9AoGXV0bnjeuqTn5ftlg 6+H1KG0+it+zwhkRw4rF5Yis1ACNNIMAM8/iKbwLBgmlMwuWSzSsnE7rSMnBIvPYZAgU u75bpTl0EK404G/jFynsam4l7A6Fm2C9rRraQqLvHIkVQr8iVyBmOZPjX46mXfOD/QCe IeMHj6AiwHCDj0v/jj1w+/v1OZ8BvaYjbPOTkRTsZcn9nkNQ5HEd9wrHfuuXx7Lf5kwj neUQ== X-Received: by 10.50.122.102 with SMTP id lr6mr4894832igb.0.1381378065134; Wed, 09 Oct 2013 21:07:45 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id p7sm11244844iga.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 21:07:44 -0700 (PDT) Sender: Mark Johnston Date: Thu, 10 Oct 2013 00:07:39 -0400 From: Mark Johnston To: Patrick Dung Subject: Re: openjdk7 dtrace support Message-ID: <20131010040739.GA65451@raichu> References: <1381209858.81219.YahooMailNeo@web193501.mail.sg3.yahoo.com> <1381326951.68334.YahooMailNeo@web193502.mail.sg3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1381326951.68334.YahooMailNeo@web193502.mail.sg3.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 04:07:46 -0000 On Wed, Oct 09, 2013 at 09:55:51PM +0800, Patrick Dung wrote: > Hello, > > > I would like to know it there is dtrace support in the openjdk7? Not yet on FreeBSD, unless there's something I'm missing. Some work needs to be done on the port in order to get it working. hotspot/make/bsd/makefiles/dtrace.make only does anything if it detects that it's running on Darwin; that'd probably be a good place to start for anyone interested in working on this. -Mark From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 10 12:06:09 2013 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 ESMTP id 8FBDE3E6; Thu, 10 Oct 2013 12:06:09 +0000 (UTC) (envelope-from admin@3dr.org) Received: from futurehost.futurehost.pl (futurehost.futurehost.pl [91.200.185.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DB7425FF; Thu, 10 Oct 2013 12:06:08 +0000 (UTC) Received: from acbt73.neoplus.adsl.tpnet.pl ([83.9.117.73]:24581 helo=ukaszBright) by futurehost.futurehost.pl with esmtpa (Exim 4.80) (envelope-from ) id 1VUF0C-000C7Q-DK; Thu, 10 Oct 2013 14:06:00 +0200 From: =?utf-8?Q?=C5=81ukasz_P?= To: "'Yamagi Burmeister'" , References: <1381232043.4996.31392865.263615DD@webmail.messagingengine.com> <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> In-Reply-To: <20131008140251.3ed4cf7e4af3415c3cde1aa9@yamagi.org> Subject: RE: Fuse on FreeBSD 9.2 Date: Thu, 10 Oct 2013 14:06:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhRsQNP9RYerwp8VXlUebUhV02GwJx2j0nAcWR9a2ZJxiTEA== Content-Language: pl Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:06:09 -0000 Hello, I've tried http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 on 9.2 - = unfortunatelly - there's the same problem as with fuse from 10. While = using MooseFS filesystem changes made on one client node are not visible = to other clients. It's like the file content is not being refreshed. There is no such = problem on 7.4 or 8.4 using regular fusefs-kmod from ports. Luke > -----Original Message----- > From: Yamagi Burmeister [mailto:lists@yamagi.org] > Sent: Tuesday, October 08, 2013 2:03 PM > To: feld@FreeBSD.org > Cc: freebsd-hackers@freebsd.org; admin@3dr.org > Subject: Re: Fuse on FreeBSD 9.2 >=20 > There's already a backport which can be found here: > http://people.freebsd.org/~flo/fusefs-kmod.tar.bz2 >=20 > 1. Download, untar and replace your existing sysutils/fusefs-kmod > port with it. Open the Makefile and add "NO_STAGE=3D yes" to it. > 2. cd sysutils/fusefs-kmod ; make makesum ; make deinstall reinstall > clean > 4. Rebuild sysutils/fusefs-libs and all fuse filesystems (don't > know if that's necessary but it doesn't hurt either). >=20 > I've been running with this kernel module on FreeBSD 9-STABLE, > 9.1 and 9.2 four about one year without any problem. I don't know why = flo@ > never committed his work. >=20 > On Tue, 08 Oct 2013 06:34:03 -0500 > Mark Felder wrote: >=20 > > On Tue, Oct 8, 2013, at 5:21, =C5=81ukasz P wrote: > > > Hello, > > > > > > Please let me know if anyone is up to fix fuse on FreeBSD 9.x ? > > > > > > Particularly this bug: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182739 > > > > > > > > > > > > I'm willing to pay for the fix. > > > > > > > > > > I think the "fix" is the new from-scratch fuse module in FreeBSD 10, > > which in my experience works flawlessly. Perhaps you should instead > > see if someone is willing to backport that fuse module to 9.x? > > _______________________________________________ > > 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" >=20 > -- > Homepage: www.yamagi.org > XMPP: yamagi@yamagi.org > GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 10 14:50:23 2013 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 ESMTP id DD9125CB for ; Thu, 10 Oct 2013 14:50:23 +0000 (UTC) (envelope-from patrick_dkt@yahoo.com.hk) Received: from nm2-vm7.bullet.mail.sg3.yahoo.com (nm2-vm7.bullet.mail.sg3.yahoo.com [106.10.148.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4ECB621F7 for ; Thu, 10 Oct 2013 14:50:22 +0000 (UTC) Received: from [106.10.166.119] by nm2.bullet.mail.sg3.yahoo.com with NNFMP; 10 Oct 2013 14:50:20 -0000 Received: from [106.10.151.202] by tm8.bullet.mail.sg3.yahoo.com with NNFMP; 10 Oct 2013 14:50:20 -0000 Received: from [127.0.0.1] by omp1014.mail.sg3.yahoo.com with NNFMP; 10 Oct 2013 14:50:20 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 923965.35000.bm@omp1014.mail.sg3.yahoo.com Received: (qmail 58297 invoked by uid 60001); 10 Oct 2013 14:50:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.hk; s=s1024; t=1381416620; bh=yVjKqongx9lyAMf/+JF64gJIEoTRF6QYOcI86a7jLZc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tr/IMA2IlAusnPLWZzvA5qMx8cU8NdyDz7c/8JLb3rlbJ0SxK+/K5PpbEhQfAKf3yQdM2Udfv/Cmp6MW64A84WMHgA+jYJH7cATdBXT+DmjU85Tp/UbwdgZDK/EVNI0jqWwwPhyECu4iPgUuMYylD/iWCCgN3wsmVdH2CYoUxvg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IoQh5u865b2oVQo5w4PpQcBNUtRbczvrckStMKC7/Ek6XLIUIbYFXRRJegVVDC0Rm0XxbPCcuvzSX6BAgIRE9gkspwkO/1MBTp/sb3YCf2Nt9Arl9+KUPWxRqMypCEBo72bFltyXwlDtUEwwLU6ztVK4jpI7e6cC6OWAn79ejLM=; X-YMail-OSG: Re4qFusVM1mTvJMYQPeK6k6eGO.ZP5PbCr9pl8HTvBU9Rq2 2zCa_XGAD39cBLwoIOua5IkxyoVZQHOZQVR.OlZVb7FGZD9MMwkdhSZ7NSGV eOMGCA.QqC5F0yn1NmdTb71fd2Cu__z0t9C8Cof6JTicOoCOuzWITVkEg_gf oT7EBHgSY8KpWoxhiW4kBH3vkFE7N7hKPmELThIGJjE8SWsvO11geP2oeoD4 5Tl7J1AFVrj9Ja_prUjnsAT9TsgeqRcy5bPFcS2DarhfvIn_1DJCESzjFoiG qpqaI03soPfeQrIvIo2U3P1xte71tE48WmBBfx49crw5QEGulAQ0sssJdJu0 00.K6IQMGyJX6t8404f.KcpwR5_ONBH3MHnBRykoOq_RBbZrYujjq_N3Sx0T mMtpd6fmLibl6XkC0CDQ3bXCmVQ4im__CzL3P2ONg9cMO8hmNRv0EEgWIVZO BKGhGb.5zmgBTcytijj0H2t1RgSsMCGAFskSoDXfvWe3QBYQqXI1htrrlqY6 J.Uw0n.LmqS0MTBNjlhB4F8pLOjpOErIudlBmhxN9d_BUJoU_fiSAJ4uyZk_ kf9WK0k0xkMIf.w-- Received: from [61.15.240.133] by web193506.mail.sg3.yahoo.com via HTTP; Thu, 10 Oct 2013 22:50:20 SGT X-Rocket-MIMEInfo: 002.001, CgoKCgpPbiBUaHVyc2RheSwgT2N0b2JlciAxMCwgMjAxMyAxMjowNyBQTSwgTWFyayBKb2huc3RvbiA8bWFya2pAZnJlZWJzZC5vcmc.IHdyb3RlOgogCk9uIFdlZCwgT2N0IDA5LCAyMDEzIGF0IDA5OjU1OjUxUE0gKzA4MDAsIFBhdHJpY2sgRHVuZyB3cm90ZToKCj4gSGVsbG8sIAo.IAo.IAo.IEkgd291bGQgbGlrZSB0byBrbm93IGl0IHRoZXJlIGlzIGR0cmFjZSBzdXBwb3J0IGluIHRoZSBvcGVuamRrNz8KCk5vdCB5ZXQgb24gRnJlZUJTRCwgdW5sZXNzIHRoZXJlJ3Mgc29tZXRoaW5nIEknbSBtaXNzaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1381209858.81219.YahooMailNeo@web193501.mail.sg3.yahoo.com> <1381326951.68334.YahooMailNeo@web193502.mail.sg3.yahoo.com> <20131010040739.GA65451@raichu> Message-ID: <1381416620.47605.YahooMailNeo@web193506.mail.sg3.yahoo.com> Date: Thu, 10 Oct 2013 22:50:20 +0800 (SGT) From: Patrick Dung Subject: Re: openjdk7 dtrace support To: Mark Johnston In-Reply-To: <20131010040739.GA65451@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Patrick Dung List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:50:23 -0000 On Thursday, October 10, 2013 12:07 PM, Mark Johnston wrote: On Wed, Oct 09, 2013 at 09:55:51PM +0800, Patrick Dung wrote: > Hello, > > > I would like to know it there is dtrace support in the openjdk7? Not yet on FreeBSD, unless there's something I'm missing. Some work needs to be done on the port in order to get it working. hotspot/make/bsd/makefiles/dtrace.make only does anything if it detects that it's running on Darwin; that'd probably be a good place to start for anyone interested in working on this. -Mark Hi Mark, Noted and thanks. The Postgresql port (9.3, not sure for 8.4/9.1/9.2) have dtrace support, which is very cool. Thanks, Patrick From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 10 21:03:14 2013 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 ESMTP id 70EFD986; Thu, 10 Oct 2013 21:03:14 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 4B0012DA2; Thu, 10 Oct 2013 21:03:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A643B986; Thu, 10 Oct 2013 17:03:13 -0400 (EDT) From: John Baldwin To: freebsd-hardware@freebsd.org Subject: Re: What's the state of AF-4Kn support? Date: Thu, 10 Oct 2013 16:57:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310101657.22675.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 10 Oct 2013 17:03:13 -0400 (EDT) Cc: Ravi Pokala , freebsd-hackers@freebsd.org, Jia-Shiun Li X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:03:14 -0000 On Monday, September 23, 2013 10:58:19 am Ravi Pokala wrote: > -----Original Message----- > From: Jia-Shiun Li > Date: Sunday, September 22, 2013 11:22 PM > To: Ravi Pokala > Cc: "freebsd-hardware@freebsd.org" , > > Subject: Re: What's the state of AF-4Kn support? > > >On Wed, Sep 18, 2013 at 10:49 PM, Ravi Pokala wrote: > >> > >>... > > > >CC -hackers. > > > >Thanks for the clarification. Is there any 4Kn HDDs shopping now? I am > >not aware of any. > > Good question. I had the impression that some currently shipping drives > were AF-4Kn, but spot-checking some of the drives listed in > > src/cam/ata/ata_da.c::ada_quirk_table[] > > against their datasheets, suggests that they're AF-512e. So, their being > flagged w/ ADA_Q_4K is "just" a performance optimization. > > >BTW I believe UFS and ZFS have proper design for 4K-sectors, but FreeBSD > >needs some ecosystem connections to get samples early to test, > >incorporate supports and validate for it. Or we will need to wait until > >it appears on market and someone got caught into some kind of bugs. > > Yeah, based on my reading of the code, it looks like the ATACAM layer and > higher (GEOM, filesystems) take the physical block size into account. That > just leaves the bootstrap code. Now that I've taken a second look, it > seems as though at least 'pmbr' only works in terms of 512 bytes. :-( Yes, the BIOS calls have always only used 512 byte sectors. There would have to be an updated spec for those, and it would be a bit of a PITA to use. I suspect the "right" answer for this on x86 is UEFI. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 10 21:03:09 2013 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 ESMTP id CEEE3977; Thu, 10 Oct 2013 21:03:09 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 A2DF42D9E; Thu, 10 Oct 2013 21:03:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 49CABB948; Thu, 10 Oct 2013 17:03:07 -0400 (EDT) From: John Baldwin To: Davide Italiano Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Date: Thu, 10 Oct 2013 16:29:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201309031507.33098.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310101629.56289.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 10 Oct 2013 17:03:08 -0400 (EDT) Cc: Kirk McKusick , alc@freebsd.org, freebsd-hackers , freebsd-fs@freebsd.org, Ivan Voras , pho@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:03:09 -0000 On Monday, October 07, 2013 1:34:24 pm Davide Italiano wrote: > > What would perhaps be better than a hardcoded reclaim age would be to use > > an LRU-type approach and perhaps set a target percent to reclaim. That is, > > suppose you were to reclaim the oldest 10% of hashes on each lowmem call > > (and make the '10%' the tunable value). Then you will always make some amount > > of progress in a low memory situation (and if the situation remains dire you > > will eventually empty the entire cache), but the effective maximum age will > > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > > throws the entire thing out on the first lowmem event. The LRU-approach would > > only throw the oldest 10% out on the first call, but eventually throw it all out > > if the situation remains dire. > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > I liked your idea more than what's available in HEAD right now and I > implemented it. > http://people.freebsd.org/~davide/review/ufs_direclaimage.diff > I was unsure what kind of heuristic I should choose to select which > (10% of) entries should be evicted so I just removed the first 10% > ones from the head of the ufs_dirhash list (which should be the > oldest). > The code keeps rescanning the cache until 10% (or, the percentage set > via SYSCTL) of the entry are freed, but probably we can discuss if > this limit could be relaxed and just do a single scan over the list. > Unfortunately I haven't a testcase to prove the effectiveness (or > non-effectiveness) of the approach but I think either Ivan or Peter > could be able to give it a spin, maybe. I think this looks good. One cosmetic nit is that I think this: if (!try_lock()) continue; else memfreed += ufsdirhash_destroy(); Looks a bit odd. I would either drop the else (which the old code did in its failsafe case) or just do this: if (try_lock()) memfreed += ufsdirhash_destroy(); -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 11 05:17:07 2013 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 ESMTP id 5516B7A0 for ; Fri, 11 Oct 2013 05:17:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C932F26A8 for ; Fri, 11 Oct 2013 05:17:06 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9B5H2uR070478; Fri, 11 Oct 2013 08:17:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9B5H2uR070478 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9B5H2ZY070477; Fri, 11 Oct 2013 08:17:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 Oct 2013 08:17:02 +0300 From: Konstantin Belousov To: Dmitry Sivachenko Subject: Re: mmap() question Message-ID: <20131011051702.GE41229@kib.kiev.ua> References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dS6nsELLbkZi5mD/" Content-Disposition: inline In-Reply-To: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 05:17:07 -0000 --dS6nsELLbkZi5mD/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 09, 2013 at 03:42:27PM +0400, Dmitry Sivachenko wrote: > Hello! >=20 > I have a program which mmap()s a lot of large files (total size more that= RAM and I have no swap), but it needs only small parts of that files at a = time. >=20 > My understanding is that when using mmap when I access some memory region= OS reads the relevant portion of that file from disk and caches the result= in memory. If there is no free memory, OS will purge previously read part= of mmap'ed file to free memory for the new chunk. >=20 > But this is not the case. I use the following simple program which gets = list of files as command line arguments, mmap()s them all and then selects = random file and random 1K parts of that file and computes a XOR of bytes fr= om that region. > After some time the program dies: > pid 63251 (a.out), uid 1232, was killed: out of swap space >=20 > It seems I incorrectly understand how mmap() works, can you please clarif= y what's going wrong? >=20 > I expect that program to run indefinitely, purging some regions out of RA= M and reading the relevant parts of files. >=20 You did not specified several very important parameters for your test: 1. total amount of RAM installed 2. count of the test files and size of the files 3. which filesystem files are located at 4. version of the system. --dS6nsELLbkZi5mD/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSV4nNAAoJEJDCuSvBvK1BTasQAIJrIGGMZ8NGSsbVdctIqLDk m2rfa8lzM9HjH2LucSFFMxSOnPmv6M5l7AadO3wmuItF6mgOlyFMojNxX2SpxXsQ SZ9AlIDgGGdRkBh4b+QZCNc1vy1E33wolhY8K1Kjn0dt54yr3O9SeTfHBfFJpFH9 Ty9OUtLxw54/s4vTIt8h8URCyP1s3IntOwqFXJGWgVnJ4IUO47gIUJTOt3N4t7KY zhFRpA7lqkdaL+6zWOKhU68cDL/yXnJ0S3b9iJxMLMq+W1TThHcQpzQKCqXpy5d3 i5Rsd2YjiR6tr3a/ONSfjeRD0Js/Nh7wSVnzb71y5b+l9tdqwFOLu2MlqzuPLMgR D3S2bPY4qe3RKlSEP9wmADmI6b6zw24M1+KLsPybHd3lM7oOB/bIipBbprM2HnJc 1/moz0oBtJayONFZap3waNlikyNOFEMj4HDZEB/L/udo9bp6hDetAFVjeXWHVnMS 2+tM4dE7U9LfYyTa6tK901jF+ZlRILAOaOYA78Oq9RQqbtHl/X7G9G4vx2tFJ3eP 35wNA8ocll+yK3qO67/u9s0y9p4N1rawLWiIeyEmaMhIIDvSzvpiweXvRAKCa7FM PLRSxuVkG2PBwd+JUxMGRiIRJkil2ZOhjS47Ngu+RDON0pKwG9hjqOM9BAg1KuFf CzI/Jk1cynvlGnSV10in =ApAb -----END PGP SIGNATURE----- --dS6nsELLbkZi5mD/-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 11 05:57:29 2013 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 ESMTP id 26613DE3 for ; Fri, 11 Oct 2013 05:57:29 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A296528A5 for ; Fri, 11 Oct 2013 05:57:28 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id x18so2975004lbi.31 for ; Thu, 10 Oct 2013 22:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9U9XUUcvh8qK2WVIt3qJOCjItz6xW42OwOaHWrujU+g=; b=bsogWxjTcudiXWiI61ATl4r8X63Cw1WocypcnxX8L28bxfABS+2ggHo/VYgvY07vmC oWEOAYID5Wdcms5U0Xz0yk33djvHR6eSeedxJjBM5gb3yzz3GYjzEglHMTNAjfNwjNoa Grz/pR7fkjpEIXcM1KMK+7BGXf4iJ7fOjvk3M8fQUc8rGbPcUcoKguU5/IdfoUjIMpVk HvyOliG4fCvi3/ty0IXexWfWUGVAqS0wMqBcCE91Kqqgb1QrHQ1nU49d8s1Xzkx2Wtus yvX2ZflA/SN+sjkhqJw+Ma91EIUe7x+hcYTY4HmztL31JhzVzPbHXAGQMn/xB5V2Paex oedg== X-Received: by 10.112.42.68 with SMTP id m4mr15407678lbl.4.1381471046645; Thu, 10 Oct 2013 22:57:26 -0700 (PDT) Received: from [10.0.1.20] (ip-95-220-138-189.bb.netbynet.ru. [95.220.138.189]) by mx.google.com with ESMTPSA id js17sm43503143lab.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Oct 2013 22:57:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: mmap() question From: Dmitry Sivachenko In-Reply-To: <20131011051702.GE41229@kib.kiev.ua> Date: Fri, 11 Oct 2013 09:57:24 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> <20131011051702.GE41229@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Fri, 11 Oct 2013 11:55:30 +0000 Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 05:57:29 -0000 On 11.10.2013, at 9:17, Konstantin Belousov wrote: > On Wed, Oct 09, 2013 at 03:42:27PM +0400, Dmitry Sivachenko wrote: >> Hello! >>=20 >> I have a program which mmap()s a lot of large files (total size more = that RAM and I have no swap), but it needs only small parts of that = files at a time. >>=20 >> My understanding is that when using mmap when I access some memory = region OS reads the relevant portion of that file from disk and caches = the result in memory. If there is no free memory, OS will purge = previously read part of mmap'ed file to free memory for the new chunk. >>=20 >> But this is not the case. I use the following simple program which = gets list of files as command line arguments, mmap()s them all and then = selects random file and random 1K parts of that file and computes a XOR = of bytes from that region. >> After some time the program dies: >> pid 63251 (a.out), uid 1232, was killed: out of swap space >>=20 >> It seems I incorrectly understand how mmap() works, can you please = clarify what's going wrong? >>=20 >> I expect that program to run indefinitely, purging some regions out = of RAM and reading the relevant parts of files. >>=20 >=20 > You did not specified several very important parameters for your test: > 1. total amount of RAM installed 24GB > 2. count of the test files and size of the files To be precise: I used 57 files with size varied form 74MB to 19GB. The total size of these files is 270GB. > 3. which filesystem files are located at UFS @ SSD drive > 4. version of the system. FreeBSD 9.2-PRERELEASE #0 r254880M: Wed Aug 28 11:07:54 MSK 2013= From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 11 19:50:28 2013 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 ESMTP id 439604A8; Fri, 11 Oct 2013 19:50:28 +0000 (UTC) (envelope-from rp_freebsd@mac.com) Received: from nk11p00mm-asmtp001.mac.com (nk11p00mm-asmtp001.mac.com [17.158.161.0]) by mx1.freebsd.org (Postfix) with ESMTP id 254552E9D; Fri, 11 Oct 2013 19:50:27 +0000 (UTC) Received: from nk11p00mm-spool004.mac.com ([17.158.161.119]) by nk11p00mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0MUI004Y1PMHVW70@nk11p00mm-asmtp001.mac.com>; Fri, 11 Oct 2013 18:49:32 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-10-11_07:2013-10-11,2013-10-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1310110081 MIME-version: 1.0 Received: from localhost ([17.158.233.93]) by nk11p00mm-spool004.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0MUI00GQNPMHKN20@nk11p00mm-spool004.mac.com>; Fri, 11 Oct 2013 18:49:29 +0000 (GMT) To: John Baldwin From: Ravi Pokala Subject: Re: What's the state of AF-4Kn support? Date: Fri, 11 Oct 2013 18:49:29 +0000 (GMT) X-Mailer: iCloud MailClient1T.110221 MailServer1T32 X-Originating-IP: [66.2.48.195] Message-id: <4a88054e-d435-4d4b-959b-eb809b99e34d@me.com> In-reply-to: <201310101657.22675.jhb@freebsd.org> X-Mailman-Approved-At: Fri, 11 Oct 2013 20:11:03 +0000 Content-Type: text/plain; CHARSET=US-ASCII; format=flowed Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, Jia-Shiun Li , freebsd-hardware@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 19:50:28 -0000 Yes, the BIOS calls have always only used 512 byte sectors. There would have to be an updated spec for those, and it would be a bit of a PITA to use. I suspect the "right" answer for this on x86 is UEFI. Yeah, that's the conclusion I reached as well. Though it occurs to me, aren't we already part-way there w/ our IA64 support? EFI originated w/ Itanium and was required to boot those systems, so shouldn't we be able to leverage much of that work for (U)EFI on amd64? In any case, the primary motivator (at least, for me) is being able to boot from AF-4Kn drives; based on the most recent roadmaps I've seen, the enterprise HDD vendors are committing to support AF-512e for a good while longer, so it's not as urgent as I thought it was when I opened this thread a few weeks ago. Thanks, --rp On Oct 10, 2013, at 01:57 PM, John Baldwin wrote: On Monday, September 23, 2013 10:58:19 am Ravi Pokala wrote: -----Original Message----- From: Jia-Shiun Li Date: Sunday, September 22, 2013 11:22 PM To: Ravi Pokala Cc: "freebsd-hardware@freebsd.org" , Subject: Re: What's the state of AF-4Kn support? >On Wed, Sep 18, 2013 at 10:49 PM, Ravi Pokala wrote: >> >>... > >CC -hackers. > >Thanks for the clarification. Is there any 4Kn HDDs shopping now? I am >not aware of any. Good question. I had the impression that some currently shipping drives were AF-4Kn, but spot-checking some of the drives listed in src/cam/ata/ata_da.c::ada_quirk_table[] against their datasheets, suggests that they're AF-512e. So, their being flagged w/ ADA_Q_4K is "just" a performance optimization. >BTW I believe UFS and ZFS have proper design for 4K-sectors, but FreeBSD >needs some ecosystem connections to get samples early to test, >incorporate supports and validate for it. Or we will need to wait until >it appears on market and someone got caught into some kind of bugs. Yeah, based on my reading of the code, it looks like the ATACAM layer and higher (GEOM, filesystems) take the physical block size into account. That just leaves the bootstrap code. Now that I've taken a second look, it seems as though at least 'pmbr' only works in terms of 512 bytes. :-( Yes, the BIOS calls have always only used 512 byte sectors. There would have to be an updated spec for those, and it would be a bit of a PITA to use. I suspect the "right" answer for this on x86 is UEFI. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 12 09:59:28 2013 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 ESMTP id CE484DE9 for ; Sat, 12 Oct 2013 09:59:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51FBC247A for ; Sat, 12 Oct 2013 09:59:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9C9xJlQ041468; Sat, 12 Oct 2013 12:59:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9C9xJlQ041468 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9C9xJkD041467; Sat, 12 Oct 2013 12:59:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Oct 2013 12:59:19 +0300 From: Konstantin Belousov To: Dmitry Sivachenko Subject: Re: mmap() question Message-ID: <20131012095919.GI41229@kib.kiev.ua> References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> <20131011051702.GE41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5dWm/iFn9ihQcn0U" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 09:59:28 -0000 --5dWm/iFn9ihQcn0U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 11, 2013 at 09:57:24AM +0400, Dmitry Sivachenko wrote: >=20 > On 11.10.2013, at 9:17, Konstantin Belousov wrote: >=20 > > On Wed, Oct 09, 2013 at 03:42:27PM +0400, Dmitry Sivachenko wrote: > >> Hello! > >>=20 > >> I have a program which mmap()s a lot of large files (total size more t= hat RAM and I have no swap), but it needs only small parts of that files at= a time. > >>=20 > >> My understanding is that when using mmap when I access some memory reg= ion OS reads the relevant portion of that file from disk and caches the res= ult in memory. If there is no free memory, OS will purge previously read p= art of mmap'ed file to free memory for the new chunk. > >>=20 > >> But this is not the case. I use the following simple program which ge= ts list of files as command line arguments, mmap()s them all and then selec= ts random file and random 1K parts of that file and computes a XOR of bytes= from that region. > >> After some time the program dies: > >> pid 63251 (a.out), uid 1232, was killed: out of swap space > >>=20 > >> It seems I incorrectly understand how mmap() works, can you please cla= rify what's going wrong? > >>=20 > >> I expect that program to run indefinitely, purging some regions out of= RAM and reading the relevant parts of files. > >>=20 > >=20 > > You did not specified several very important parameters for your test: > > 1. total amount of RAM installed >=20 >=20 > 24GB >=20 >=20 > > 2. count of the test files and size of the files >=20 > To be precise: I used 57 files with size varied form 74MB to 19GB. > The total size of these files is 270GB. >=20 > > 3. which filesystem files are located at >=20 >=20 > UFS @ SSD drive >=20 > > 4. version of the system. >=20 >=20 > FreeBSD 9.2-PRERELEASE #0 r254880M: Wed Aug 28 11:07:54 MSK 2013 I was not able to reproduce the situation locally. I even tried to start a lot of threads accessing the mapped regions, to try to outrun the pagedaemon. The user threads sleep on the disk read, while pagedaemon has a lot of time to rebalance the queues. It might be a case when SSD indeed makes a difference. Still, I see how this situation could appear. The code, which triggers OOM, never fires if there is a free space in the swapfile, so the absense of swap is neccessary condition to trigger the bug. Next, OOM calculation does not account for a possibility that almost all pages on the queues can be reused. It just fires if free pages depleted too much or free target cannot be reached. IMO one of the possible solution is to account the queued pages in addition to the swap space. This is not entirely accurate, since some pages on the queues cannot be reused, at least transiently. Most precise algorithm would count the hold and busy pages globally, and substract this count from queues length, but it is probably too costly. Instead, I think we could rely on the numbers which are counted by pagedaemon threads during the passes. Due to the transient nature of the pagedaemon failures, this should be fine. Below is the prototype patch, against HEAD. It is not applicable to stable, please use HEAD kernel for test. diff --git a/sys/sys/vmmeter.h b/sys/sys/vmmeter.h index d2ad920..ee5159a 100644 --- a/sys/sys/vmmeter.h +++ b/sys/sys/vmmeter.h @@ -93,9 +93,10 @@ struct vmmeter { u_int v_free_min; /* (c) pages desired free */ u_int v_free_count; /* (f) pages free */ u_int v_wire_count; /* (a) pages wired down */ - u_int v_active_count; /* (q) pages active */ + u_int v_active_count; /* (a) pages active */ u_int v_inactive_target; /* (c) pages desired inactive */ - u_int v_inactive_count; /* (q) pages inactive */ + u_int v_inactive_count; /* (a) pages inactive */ + u_int v_queue_sticky; /* (a) pages on queues but cannot process */ u_int v_cache_count; /* (f) pages on cache queue */ u_int v_cache_min; /* (c) min pages desired on cache queue */ u_int v_cache_max; /* (c) max pages in cached obj (unused) */ diff --git a/sys/vm/vm_meter.c b/sys/vm/vm_meter.c index 713a2be..4bb1f1f 100644 --- a/sys/vm/vm_meter.c +++ b/sys/vm/vm_meter.c @@ -316,6 +316,7 @@ VM_STATS_VM(v_active_count, "Active pages"); VM_STATS_VM(v_inactive_target, "Desired inactive pages"); VM_STATS_VM(v_inactive_count, "Inactive pages"); VM_STATS_VM(v_cache_count, "Pages on cache queue"); +VM_STATS_VM(v_queue_sticky, "Pages which cannot be moved from queues"); VM_STATS_VM(v_cache_min, "Min pages on cache queue"); VM_STATS_VM(v_cache_max, "Max pages on cached queue"); VM_STATS_VM(v_pageout_free_min, "Min pages reserved for kernel"); diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 7846702..6943a0e 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -226,6 +226,7 @@ struct vm_domain { long vmd_segs; /* bitmask of the segments */ boolean_t vmd_oom; int vmd_pass; /* local pagedaemon pass */ + int vmd_queue_sticky; /* pages on queues which cannot be processed */ struct vm_page vmd_marker; /* marker for pagedaemon private use */ }; =20 diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 5660b56..a62cf97 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -896,7 +896,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) { vm_page_t m, next; struct vm_pagequeue *pq; - int page_shortage, maxscan, pcount; + int failed_scan, page_shortage, maxscan, pcount; int addl_page_shortage; vm_object_t object; int act_delta; @@ -960,6 +960,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) */ pq =3D &vmd->vmd_pagequeues[PQ_INACTIVE]; maxscan =3D pq->pq_cnt; + failed_scan =3D 0; vm_pagequeue_lock(pq); queues_locked =3D TRUE; for (m =3D TAILQ_FIRST(&pq->pq_pl); @@ -1012,6 +1013,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) vm_page_unlock(m); VM_OBJECT_WUNLOCK(object); addl_page_shortage++; + failed_scan++; continue; } =20 @@ -1075,6 +1077,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) * loop over the active queue below. */ addl_page_shortage++; + failed_scan++; goto relock_queues; } =20 @@ -1229,6 +1232,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) */ if (vm_page_busied(m)) { vm_page_unlock(m); + failed_scan++; goto unlock_and_continue; } =20 @@ -1241,6 +1245,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) vm_page_requeue_locked(m); if (object->flags & OBJ_MIGHTBEDIRTY) vnodes_skipped++; + failed_scan++; goto unlock_and_continue; } vm_pagequeue_unlock(pq); @@ -1386,6 +1391,11 @@ relock_queues: m =3D next; } vm_pagequeue_unlock(pq); + + atomic_add_int(&cnt.v_queue_sticky, failed_scan - + vmd->vmd_queue_sticky); + vmd->vmd_queue_sticky =3D failed_scan; + #if !defined(NO_SWAPPING) /* * Idle process swapout -- run once per second. @@ -1433,10 +1443,15 @@ static int vm_pageout_oom_vote; static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass) { + u_int queues_count; int old_vote; =20 - if (pass <=3D 1 || !((swap_pager_avail < 64 && vm_page_count_min()) || - (swap_pager_full && vm_paging_target() > 0))) { + queues_count =3D cnt.v_active_count + cnt.v_inactive_count - + cnt.v_queue_sticky; + if (pass <=3D 1 || !((swap_pager_avail < 64 && vm_page_count_min() && + queues_count <=3D cnt.v_free_min) || + (swap_pager_full && vm_paging_target() > 0 && + queues_count <=3D vm_paging_target()))) { if (vmd->vmd_oom) { vmd->vmd_oom =3D FALSE; atomic_subtract_int(&vm_pageout_oom_vote, 1); --5dWm/iFn9ihQcn0U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSWR12AAoJEJDCuSvBvK1BkrYQAJR8fizQoKk5TsYKqLlpKxMq 5zMDpeRcr3yLDZjkCAUDFGh+EXrMOtKDpaBojQvAdsMPSaexpzUxKSRrbGKGhwfv AjUQXMEoKq/1JvMX5QQflfybs8r60PTTyvYnamFC0oQr+1Bdba7XlMb9XWFaiXD4 jUvGGT01VCXfvdi7UXUoi77FHGHsw/a8FdzSWNSVtkmHY6hhLIYgxpvX+agD8e8O 0TcuMCACyF9HuRsmS3RnXgSy3IQrpJApw1b8R6UxpIgUR9O34avZVib68/vyosvY gm9qoihTkEJquvdvbpIstw/CP0KfpHJQHXW7nhVOomfByyowGYt0dJ7+Derf77ag Xc4Bi0c2bASspEWsyOmcgCn1gdN3HgDotTtO6FRMRwVyhV5rIh2OovUnIqLH1TS0 YqFV0jt7hygoyttzU5ei5cAFpWFOhdAbNfkUuEbggk/VXZEvaiZUR4/IoNLR7Ce1 BjctqAOdZAukGkqXIJHGURiKvwf9arQEyI2Aq9jJExc01HG/Dub8LDj4YSpFNjIY OYMe7EBmLZ145xLiCZQU71VGw/XJlpAgQocc0+Lz+4HHZ70R7PmtCxUpLviNmweu 0I6BopZNpYLu5nHsxyBKxYdRCvICTOsSUIaF4QXgEgGnLeGFuViRufJm5dmfQNII EoaeckHA8AVHnTInQVUc =m+Yx -----END PGP SIGNATURE----- --5dWm/iFn9ihQcn0U-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 12 12:04:35 2013 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 ESMTP id 676D587F for ; Sat, 12 Oct 2013 12:04:35 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E5CBE2A4C for ; Sat, 12 Oct 2013 12:04:34 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ev20so4158406lab.25 for ; Sat, 12 Oct 2013 05:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rK6Lc9bVb7nCcxRRPBYBk+cQ4uvBf84lAT0dFAMSxdA=; b=HcMiVRpH4D5L6MhsESe6jo2XNK646ovSmLdDfNWFyczfzkRjkdc6rHQZ6Q6eA5DyzI yeWsv4IYnPSkuZza8lCwgfz/qsGu0udlpAMkxCy0PEUXNQm6Omafc2vMQlZO7ogM67Rl Cg/+0DdCxUnJ3u4sKbi2BSyJXM3YcKy9NxRxXDrbDsuOPdQC1n2wuphq6Ll66tFuco0D +iIMvbnrij3Rbc9re5k4ev+SUR5syzzqoAdjKX+3NlXAQv/SFTHf+IxCPSCgUVLuc3Uf mdDtDQsYWaw/qhnht7QhGm71tJmO0ks+eIuvPEV6T8j4R5+JkhtwdTt2JuUsKtesHAAf XUGQ== X-Received: by 10.112.172.137 with SMTP id bc9mr21149298lbc.21.1381579472921; Sat, 12 Oct 2013 05:04:32 -0700 (PDT) Received: from [10.0.1.20] ([176.193.142.218]) by mx.google.com with ESMTPSA id pw4sm36690769lbb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Oct 2013 05:04:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: mmap() question From: Dmitry Sivachenko In-Reply-To: <20131012095919.GI41229@kib.kiev.ua> Date: Sat, 12 Oct 2013 16:04:31 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> <20131011051702.GE41229@kib.kiev.ua> <20131012095919.GI41229@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Sat, 12 Oct 2013 12:15:09 +0000 Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 12:04:35 -0000 On 12.10.2013, at 13:59, Konstantin Belousov = wrote: >=20 > I was not able to reproduce the situation locally. I even tried to = start > a lot of threads accessing the mapped regions, to try to outrun the > pagedaemon. The user threads sleep on the disk read, while pagedaemon > has a lot of time to rebalance the queues. It might be a case when SSD > indeed makes a difference. >=20 With ordinary SATA drive it will take hours just to read 20GB of data = from disk because of random access, it will do a lot of seeks and = reading speed will be extremely low. SSD dramatically improves reading speed. > Still, I see how this situation could appear. The code, which triggers > OOM, never fires if there is a free space in the swapfile, so the > absense of swap is neccessary condition to trigger the bug. Next, OOM > calculation does not account for a possibility that almost all pages = on > the queues can be reused. It just fires if free pages depleted too = much > or free target cannot be reached. First I tried with some swap space configured. The OS started to swap = out my process after it reached about 20GB which is also not what I = expected: what is the reason to swap out regions of read-only mmap()ed = files? Is it the expected behaviour? >=20 > Below is the prototype patch, against HEAD. It is not applicable to > stable, please use HEAD kernel for test. Thanks, I will test the patch soon and report the results.= From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 12 14:14:46 2013 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 ESMTP id 4F83DDCF for ; Sat, 12 Oct 2013 14:14:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF7D72F54 for ; Sat, 12 Oct 2013 14:14:45 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9CEEerh095729; Sat, 12 Oct 2013 17:14:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9CEEerh095729 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9CEEeUi095728; Sat, 12 Oct 2013 17:14:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Oct 2013 17:14:40 +0300 From: Konstantin Belousov To: Dmitry Sivachenko Subject: Re: mmap() question Message-ID: <20131012141440.GN41229@kib.kiev.ua> References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> <20131011051702.GE41229@kib.kiev.ua> <20131012095919.GI41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zcUUBUpUFZiSJJc8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 14:14:46 -0000 --zcUUBUpUFZiSJJc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 12, 2013 at 04:04:31PM +0400, Dmitry Sivachenko wrote: >=20 > On 12.10.2013, at 13:59, Konstantin Belousov wrote: > >=20 > > I was not able to reproduce the situation locally. I even tried to start > > a lot of threads accessing the mapped regions, to try to outrun the > > pagedaemon. The user threads sleep on the disk read, while pagedaemon > > has a lot of time to rebalance the queues. It might be a case when SSD > > indeed makes a difference. > >=20 >=20 >=20 > With ordinary SATA drive it will take hours just to read 20GB of data fro= m disk because of random access, it will do a lot of seeks and reading spee= d will be extremely low. >=20 > SSD dramatically improves reading speed. >=20 >=20 > > Still, I see how this situation could appear. The code, which triggers > > OOM, never fires if there is a free space in the swapfile, so the > > absense of swap is neccessary condition to trigger the bug. Next, OOM > > calculation does not account for a possibility that almost all pages on > > the queues can be reused. It just fires if free pages depleted too much > > or free target cannot be reached. >=20 >=20 > First I tried with some swap space configured. The OS started to swap ou= t my process after it reached about 20GB which is also not what I expected:= what is the reason to swap out regions of read-only mmap()ed files? Is i= t the expected behaviour? >=20 How did you concluded that the pages from your r/o mappings were paged out ? VM never does this. Only anonymous memory could be written to swap file, including the shadow pages for the writeable COW mappings. I suspect that you have another 20GB of something used on the machine meantime. >=20 > >=20 > > Below is the prototype patch, against HEAD. It is not applicable to > > stable, please use HEAD kernel for test. >=20 >=20 > Thanks, I will test the patch soon and report the results. --zcUUBUpUFZiSJJc8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSWVlQAAoJEJDCuSvBvK1B3CIP/jUucHTlJZfE3Sx63ctQ4WvJ ZrJxgkETpmZLty7Llb73oJIw3jro4shk13zNVJS0wr1rJ9uBd/Nj6sChMb7cPI/V gN8s0tGV2RxNClnt5inWjGdWG0L8dadkru3m67wUr1xpvFCY3wL3XKTNO5qceoy+ 40Yyu+EFQG1leRS2lw8KoCDV3zhILHvs5CALQ0KXz5tyNVPcQfr6HxNtfDwoD4AI bavv4gPCyqBHVSam8M2Dzig63N4C0XFVwz/kg5FqLDlp4TvwHCjnn0/zFFEz+a6p gOtx7txeRmeXe6FJEGCYvHX+nush3dTSptUpH3/0skOtHcXMAgjnFbkmyGEL8C9q wPJGB+gv3DKpZtqF5aDUJeKLKXnC28gjz3yXQGcwkdMcZzwbsA/AjPdced0JIb18 ENUDxEqPEmBG82MBHJxz5gFmB2DW4ipp+dTg4z+Mf4/aSdbzz9SImuL8R2GtRgdm BTYXjfOjGGm6Chh4GYIn7vyRcCXTB7HXt7nHAHojYv9/oCqny4DW8YAzZvQcG3no z/e5VlvGWUQBiGaA8luaCUd0u4jGlC2PCZdGSPvmOdHM+zd0Dkno6sTZYHypm/zz b+5/RlE8GehceRY7hRFIgNJ1MbedsCtxN5/yyaspldkB2YnX0QcWtyJqOx1aD1t7 xh/NKbSxcJarZsSzMzEz =oOIh -----END PGP SIGNATURE----- --zcUUBUpUFZiSJJc8--