From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 05:10:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75AB8106564A for ; Mon, 14 Mar 2011 05:10:56 +0000 (UTC) (envelope-from ravi.murty@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 052488FC20 for ; Mon, 14 Mar 2011 05:10:55 +0000 (UTC) Received: by bwz12 with SMTP id 12so4637827bwz.13 for ; Sun, 13 Mar 2011 22:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=uTBIUVIJTUmdechKyTEIg2frZ65jJ5fWUiR1rGx2110=; b=at9X0vi/56XKvArCfspX0Ftj2NQ/zFcolEt2+ze7TBPM4jIP2h7iMn5AaLpynnuGsW JO54olIs6cU55TXBVKBVGaTwl8IBVHnXns33xpkpU+Tmc+Ukk4f2vwqFxzjoVlTpu0Tp 8bG8JtKmVdgUXP3YestVBqY/1jZgxFC2b8KN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EGyxMh31hKqDKx/d0ugjTDNc/XbD3Zz1Uu0FNCPT4BeHIyEaV7ei2s4RBQIWcC/CxJ bW+8wOA6Foj3ADnj7zgC52beiwXBcTKRVfT5k6X1GbKTzGaVM8SXxQAU5NMJYHnmql+m sMPBlrVJAspYf0gxmRtVt1O7aAXzTebAO63fY= MIME-Version: 1.0 Received: by 10.204.19.76 with SMTP id z12mr1562762bka.205.1300077682001; Sun, 13 Mar 2011 21:41:22 -0700 (PDT) Received: by 10.204.117.193 with HTTP; Sun, 13 Mar 2011 21:41:21 -0700 (PDT) Date: Sun, 13 Mar 2011 21:41:21 -0700 Message-ID: From: Ravi Murty To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SIGSTOP and SIGKILL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 05:10:56 -0000 Hi everybody, I'm using FreeBSD 8.0 and I seem to have a race condition that is fairly reproducible. Let me try and describe it. The basic idea is that we use SIGSTOP and SIGCONT to stop and restart threads of a process - call it p1. A caller (call it c1) SIGSTOPs and SIGCONTs p1 until another caller (call it c2) decides to come along and kill the process. Both callers grab proc_lock for p1 and use pfind(...) to find the process before subjecting p1 to any of these signals. What I see is that SIGKILL is somehow ignored in favor for SIGSTOP and process (and all of its threads somehow end up suspended). As a side note, we changed our implementation to "post" SIGKILL to all threads of p1 because of another race we discovered. In this case the thread selected by psignal/tdsignal happened to be in thr_exit() on its way to dying. Becuse it was still on the list of available threads for the process, it was picked (FIRST_TD_IN_PROC) but because it was in thr_exit it dies taking SIGKILL with it. What I see in this new race is the following. We post SIGKILL on every thread of the process and c2 leaves releasing p2's proc_lock. As each thread returns to ring3 via the trap handler it sees that it has a signal to deal with and calls cursig and postsig. In the code, postsig eventually calls sigexit (default behavior) which via exit1 calls thread_suspend_check causing threads to kill themselves as long as the first thread that is here calls thread_single(SINGLE_EXIT). In our case, the process (which is still on the global all_proc list) is subjected to SIGSTOP which sets the P_STOPPED_SIG flag to p1. As each thread makes its way through thread_suspend_check it suspends itself becuase P_SHOULDSTOP ends up being true. In the end I end up with a process whose threads have taken SIGKILL (I can dump each threads state and look at its siglist to see no signals) but the process hasn't died. This seems odd. It would seem that any signals posted after the process receives a SIGKILL should be ignore but how do we detect that specially after SIGKILL is cleared from the siglist because it is in the middle of taking the signal. Alternatively if the signal being taken is SIGKILL the kernel needs to avoid saying "I'll stop the process now because I've been asked to". Any good solutions to this problem? Thanks Ravi Murty From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 06:30:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26D07106564A for ; Mon, 14 Mar 2011 06:30:08 +0000 (UTC) (envelope-from ravi.murty@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D2E688FC08 for ; Mon, 14 Mar 2011 06:30:07 +0000 (UTC) Received: by iwn33 with SMTP id 33so5492158iwn.13 for ; Sun, 13 Mar 2011 23:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=aJ1yD6Q/92R83Fv5BaHOaJa3NtI4wL6qKirfB4U7jRU=; b=I+xutK3L2CcBvj/sHtC8dM74vHweBkcxlWqjkV+jkGylqzsV0LE47epXLICL50FEXo jzD3zIw0FvP6l4ZoEASvRcxcfpcVaarjTTxUAlYQWRjppSmFi3dY88cWwtFMYr77nZil uC2w6IuXIEmYMeHoBaWz6j8GkEGH5sFYHKFOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=uGlmtfwWhQNZstJpXIG9Qyo0PW7b8Q4b057BqMfRfBluQlqovZA3qc6YpubN5t8p1N +u/Sms9Jlr3ot9z4OjV8i/VfSiqUx8fseTss8wtksYAqceRgS1dgSJko4s/Wc/lhwwXI /lv4W67t1xKqE+4Ek1cyQuzsS92hwAeFVBRAk= Received: by 10.43.60.206 with SMTP id wt14mr8665801icb.399.1300084207211; Sun, 13 Mar 2011 23:30:07 -0700 (PDT) Received: from [192.168.1.5] ([96.225.221.162]) by mx.google.com with ESMTPS id u9sm6354276ibe.14.2011.03.13.23.30.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Mar 2011 23:30:05 -0700 (PDT) References: <201103141230.49277.erich@alogreentechnologies.com> In-Reply-To: <201103141230.49277.erich@alogreentechnologies.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Ravi Murty Date: Sun, 13 Mar 2011 23:30:00 -0700 To: Erich Dollansky Cc: "freebsd-hackers@freebsd.org" Subject: Re: SIGSTOP and SIGKILL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 06:30:08 -0000 I haven't, are there specific improvements in this area of the kernel? On Mar 13, 2011, at 10:30 PM, Erich Dollansky wrote: > Hi, >=20 > On Monday 14 March 2011 11:41:21 Ravi Murty wrote: >=20 >>=20 >> Any good solutions to this problem? >=20 > did you try your program on 8.2? >=20 > Erich From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 07:02:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F116A106564A for ; Mon, 14 Mar 2011 07:02:28 +0000 (UTC) (envelope-from fordearlinux@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id C386F8FC15 for ; Mon, 14 Mar 2011 07:02:28 +0000 (UTC) Received: by pxi6 with SMTP id 6so3330469pxi.17 for ; Mon, 14 Mar 2011 00:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=YX4rA+FcprKe5AXMqNBZoZlF2J9FeFTPxFZYT2ajDHI=; b=WK71oDanmffmrDPzzKbwXPH9xkWeJyQgV2YVGDb9/JbPsLwKGE0o8I5YPyYX3wj82h aPvaXjRYSGyVZiG29DeK95DWz+sjesYsEu47SGtaAJ/yGGFlM9c8D13PeZjWcMNzgfYF lugVRpf8RhtKv4T+xDsgTIqX6Ry575JT1kInk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=OACoJLqJVkZGbqR68MkOix89eXLA84bcMFpYYqmkkIYE439o0mmFYBwWuzX/QuSSdB 4LpwHS3RmtSrHb/Z6g0XiLYw5cCbi4+hhuRsu8QejBrxTib8p+QamdBDbWmNOXKNuT2O 0jLgrQ2VrGqucxPC/SbG6CwCN7tCpfNTK/M3s= Received: by 10.143.170.7 with SMTP id x7mr10219587wfo.34.1300084250761; Sun, 13 Mar 2011 23:30:50 -0700 (PDT) Received: from [192.168.2.3] ([111.92.11.243]) by mx.google.com with ESMTPS id m10sm9806674wfl.11.2011.03.13.23.30.48 (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 23:30:50 -0700 (PDT) Message-ID: <4D7DB613.4020509@gmail.com> Date: Mon, 14 Mar 2011 12:00:43 +0530 From: shivanth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: About implementation of kqueues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 07:02:29 -0000 Can somebody help me with the details of implementation of the kqueue and kevent Api's .I need to know about the internals , thoae related to knotes. Thank You shivanth From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 07:28:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A75106564A for ; Mon, 14 Mar 2011 07:28:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 89A918FC17 for ; Mon, 14 Mar 2011 07:28:46 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p2E7SfNd071130 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Mar 2011 00:28:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D7DC3B2.1090507@freebsd.org> Date: Mon, 14 Mar 2011 00:28:50 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: shivanth References: <4D7DB613.4020509@gmail.com> In-Reply-To: <4D7DB613.4020509@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: About implementation of kqueues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 07:28:46 -0000 On 3/13/11 11:30 PM, shivanth wrote: > Can somebody help me with the details of implementation of the > kqueue and kevent Api's .I need to know about the internals , thoae > related to knotes. the original paper is the best reference http://people.*freebsd*.org/~jlemon/papers/*kqueue*.pdf > > Thank You > shivanth > _______________________________________________ > 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 Mon Mar 14 07:30:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D61EE106566C for ; Mon, 14 Mar 2011 07:30:17 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9A06E8FC12 for ; Mon, 14 Mar 2011 07:30:17 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id p2E77F56000632; Mon, 14 Mar 2011 01:07:21 -0600 From: Erich Dollansky To: Ravi Murty Date: Mon, 14 Mar 2011 14:07:10 +0700 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.5.4; amd64; ; ) References: <201103141230.49277.erich@alogreentechnologies.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103141407.11052.erichfreebsdlist@ovitrap.com> Cc: "freebsd-hackers@freebsd.org" Subject: Re: SIGSTOP and SIGKILL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 07:30:17 -0000 Hi, On Monday 14 March 2011 13:30:00 Ravi Murty wrote: > I haven't, are there specific improvements in this area of the kernel? I do not know for sure. Just check the release notes. I only know of this: 20100125: Introduce the kernel thread "deadlock resolver" (which can be enabled via the DEADLKRES option, see NOTES for more details) and the sleepq_type() function for sleepqueues. Erich > > On Mar 13, 2011, at 10:30 PM, Erich Dollansky wrote: > > > Hi, > > > > On Monday 14 March 2011 11:41:21 Ravi Murty wrote: > > > >> > >> Any good solutions to this problem? > > > > did you try your program on 8.2? > > > > Erich > > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 08:45:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A592A106564A for ; Mon, 14 Mar 2011 08:45:19 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 24FC78FC1C for ; Mon, 14 Mar 2011 08:45:18 +0000 (UTC) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id p2E8OonD017448; Mon, 14 Mar 2011 16:24:54 +0800 (CST) From: Kevin Lo To: shivanth In-Reply-To: <4D7DB613.4020509@gmail.com> References: <4D7DB613.4020509@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 14 Mar 2011 16:24:50 +0800 Message-ID: <1300091090.2474.1.camel@nsl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: About implementation of kqueues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 08:45:19 -0000 shivanth wrote: > Can somebody help me with the details of implementation of the kqueue > and kevent Api's .I need to know about the internals , thoae related to > knotes. I think someone already replied to your message http://leaf.dragonflybsd.org/mailarchive/kernel/2011-03/msg00025.html > Thank You > shivanth Kevin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 09:03:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F4C01065670 for ; Mon, 14 Mar 2011 09:03:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2388FC0C for ; Mon, 14 Mar 2011 09:03:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2E93Ir9036600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Mar 2011 11:03:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2E93Ij7055953; Mon, 14 Mar 2011 11:03:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2E93I6P055952; Mon, 14 Mar 2011 11:03:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 14 Mar 2011 11:03:18 +0200 From: Kostik Belousov To: Ravi Murty Message-ID: <20110314090318.GG78089@deviant.kiev.zoral.com.ua> References: <201103141230.49277.erich@alogreentechnologies.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vBwLacbGVLp/4r+w" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "freebsd-hackers@freebsd.org" , Erich Dollansky Subject: Re: SIGSTOP and SIGKILL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:03:26 -0000 --vBwLacbGVLp/4r+w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 13, 2011 at 11:30:00PM -0700, Ravi Murty wrote: > I haven't, are there specific improvements in this area of the kernel? First, the 8.2, compared to 8.0, changed the mechanism of delivering the process-global signal to a thread. Now, the thread to deliver is selected at the moment of delivery, instead of the moment of post. This was done to close a race where either thread changed signal mask after post, or exited after post, causing signal be undefinitely delayed or ignored, respectively. Second, 8.2 less often stops the threads in the sleep state, more often trying to move the thread to safer user<->kernel boundary, to take a stop. Sleeping thread might indicate the unsafe sleep (from the POV of stopping) by using PBDRY flag to msleep. Both the changes are not directly address the behaviour you described, but they are explicitely in the area of your interest. BTW, it is not clear to me, does the process in the state as you described, able to unwind from the stop state using SIGCONT ? I.e., is it 'weird but recoverable' state, or is it 'weird and unrecoverable' state ? >=20 > On Mar 13, 2011, at 10:30 PM, Erich Dollansky wrote: >=20 > > Hi, > >=20 > > On Monday 14 March 2011 11:41:21 Ravi Murty wrote: > >=20 > >>=20 > >> Any good solutions to this problem? > >=20 > > did you try your program on 8.2? > >=20 > > Erich > _______________________________________________ > 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" --vBwLacbGVLp/4r+w Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk192dUACgkQC3+MBN1Mb4h1VwCgxwjjrxGe5lW+RWej+OIAbYc7 oxsAn2kiD6Wj3ldTS/DJvfZDS/rJ0Cxo =6l8B -----END PGP SIGNATURE----- --vBwLacbGVLp/4r+w-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 06:00:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123D81065677 for ; Mon, 14 Mar 2011 06:00:27 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id C328F8FC12 for ; Mon, 14 Mar 2011 06:00:26 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id p2E5UoGt000657; Sun, 13 Mar 2011 23:30:53 -0600 From: Erich Dollansky Organization: ALO Green Technologies Pte Ltd To: freebsd-hackers@freebsd.org Date: Mon, 14 Mar 2011 12:30:49 +0700 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.5.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103141230.49277.erich@alogreentechnologies.com> X-Mailman-Approved-At: Mon, 14 Mar 2011 11:14:26 +0000 Cc: Ravi Murty Subject: Re: SIGSTOP and SIGKILL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 06:00:27 -0000 Hi, On Monday 14 March 2011 11:41:21 Ravi Murty wrote: > > Any good solutions to this problem? did you try your program on 8.2? Erich From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 11:17:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5A71065698 for ; Mon, 14 Mar 2011 11:17:36 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 550B58FC16 for ; Mon, 14 Mar 2011 11:17:36 +0000 (UTC) Received: by iwn33 with SMTP id 33so5697386iwn.13 for ; Mon, 14 Mar 2011 04:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=SMqv1+QP4CT53pSvmDVRQ8v8gwQ9JtmoesZkr23bDhg=; b=q+SAFMh60fbbsFpoE3r+O/qQ/UH3TTKy7Hz8INoEkdTox5uwOxw/s4ozUE3an/dckZ Zb+J33+QLw/FcvWlrI0SYFEHU0Rld2k2nW8zljbye+dAo+pUX91vWjFYuwVQ3xKqeYTT /8r/vHvgkZxHmjX8ikJh23bbnXvwfynhKcS/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XBONwER8AFTISpFL3EZ3MhgQ+a4eqG6zbiaZ+zX5VY6q6Y6usIDAwJYp43yAFLBg7S Zp5Z+rfs8t8+odidDXg09QSV8VfXnwPUNUGq62MsbOFMGOQ/kxNPG3isoo1c5nqg/TF6 jc/s3n3Q+Wz1xW+5MQGJyGYnxKkElwtlFi4EA= MIME-Version: 1.0 Received: by 10.42.141.197 with SMTP id p5mr85117icu.141.1300101455662; Mon, 14 Mar 2011 04:17:35 -0700 (PDT) Received: by 10.231.165.149 with HTTP; Mon, 14 Mar 2011 04:17:35 -0700 (PDT) Date: Mon, 14 Mar 2011 12:17:35 +0100 Message-ID: From: Mats Lindberg To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 11:17:36 -0000 All I am migrating from FreeBSD 6.3 to FreeBSD 8.1 And I have noticed some, what I think is, strange behaviour. In FreeBSD 6.3 when I do > swapoff -a > dd if=/dev/zero of=/tmp/whatever bs=1G count=1 I get something like "out of memory - killed" In FreeBSD 8.1 doing the same - processes around start to die, e.g. all getty's are killed and finally devfs goes the same way. My target is diskless nfs mounted to a linux fileserver - hence no swap partition It does not seem to be relalted to the nfs root however - I get the same behaviour running FBSD-8.1 in a VMWARE server session. Is this a new 'feature' of FBSD or just a bug? Are there some sysctl's to set to 'really' turn of swapping. At one instance I also got a kernel panic saying 'page fault in kernel' but I'm having a hard time to repeat just that. regards Mats From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 11:41:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E8AB1065785 for ; Mon, 14 Mar 2011 11:41:40 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 955058FC0A for ; Mon, 14 Mar 2011 11:41:38 +0000 (UTC) Received: by iyj12 with SMTP id 12so5737780iyj.13 for ; Mon, 14 Mar 2011 04:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N2SOEAe1F1CJupaQ1u47DrHeSDkoYJpbBG8/4UrHXz0=; b=gw6RI1IeLssbirt22ljNCH2klKti+wZZjCE6daV/xZtAQzUvZ3I1zpeQdpUkElGY+l 2e3OAhZidtH6fpvH5+NLHP96IXMvO2hej+1fGLS0Ffy7l3ZfnQiwvYTAH0QfMQfNozf2 91yjogTb5sbHNTN5SdK2Ss32boVibSQUsHvTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zf5KyrZX+WdSrdyyVZRoJGQcP/hPRphO9zn0s58mnM62kckfQwmFWmAxmO9r62GnB9 ud0KSENNul6SxPBVdjKnV0rLh68BeXgp2UqpcQsxZFsT0ytJIDQ+Rz5Jg3YoPlbvP305 28kulx0X/Vj+LDN0d9mOTH1sUUP51lbhLzY6Y= MIME-Version: 1.0 Received: by 10.231.28.17 with SMTP id k17mr9534271ibc.169.1300102897332; Mon, 14 Mar 2011 04:41:37 -0700 (PDT) Received: by 10.231.165.149 with HTTP; Mon, 14 Mar 2011 04:41:37 -0700 (PDT) In-Reply-To: <4D7DFC6F.80008@gmail.com> References: <4D7DFC6F.80008@gmail.com> Date: Mon, 14 Mar 2011 12:41:37 +0100 Message-ID: From: Mats Lindberg To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 11:41:40 -0000 No - not from what I understand in the vmware it looks like a real disk device /dev/ad0s1e in the nfsroot'ed system I actually have 'of=/opt/something' which is definately to the nfs disk. 2011/3/14 Mark Tinguely > On 3/14/2011 6:17 AM, Mats Lindberg wrote: > >> All >> I am migrating from FreeBSD 6.3 to FreeBSD 8.1 And I have noticed some, >> what >> I think is, strange behaviour. >> >> In FreeBSD 6.3 when I do >> >>> swapoff -a >>> dd if=/dev/zero of=/tmp/whatever bs=1G count=1 >>> >> I get something like "out of memory - killed" >> >> In FreeBSD 8.1 doing the same - processes around start to die, e.g. all >> getty's are killed and finally devfs goes the same way. >> >> My target is diskless nfs mounted to a linux fileserver - hence no swap >> partition >> It does not seem to be relalted to the nfs root however - I get the same >> behaviour running FBSD-8.1 in a VMWARE server session. >> >> Is this a new 'feature' of FBSD or just a bug? >> Are there some sysctl's to set to 'really' turn of swapping. >> >> At one instance I also got a kernel panic saying 'page fault in kernel' >> but >> I'm having a hard time to repeat just that. >> >> regards >> Mats >> _______________________________________________ >> 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 >> " >> >> Do you have /tmp mounted on a memory filesystem? > > --Mark Tinguely > > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 13:39:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23BD4106564A for ; Mon, 14 Mar 2011 13:39:04 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DB5778FC22 for ; Mon, 14 Mar 2011 13:39:03 +0000 (UTC) Received: by iwn33 with SMTP id 33so5835988iwn.13 for ; Mon, 14 Mar 2011 06:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cxgSz3+tAcy7rM4gP93R6PB3/wpUIxk+M/OJP6SP9ms=; b=sx/ElaZpH+5XLZw5Lz33cNd8AaIVzDOuizJe9TfpOaUKlTIMjAQgYYuSMJj1BjuXZy eiOMuGWxqKY9mYMSviJbCKVtprluFIBSAVYwKG4QrDjd/4k/H3zlEJ9ZxjrleclU1Nh9 1NA8t1tJFG75spwLe375cFrbVj2It1upoyfdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FePFocE59QKj0AnLUveDNMFFyeR7ZHWSIWMgFdAvJRa8arihZBlPqgDF4avABqFOWw f6EqqmqkecXir49/LwAFCcYtxWYXLpZCRGBHRlQdRiBnsee5mTHix21sX9il4FSev8m/ mtE172kNlg+d67jgIczFNe++bDy9U9vZESwTM= MIME-Version: 1.0 Received: by 10.231.28.17 with SMTP id k17mr9614900ibc.169.1300109943138; Mon, 14 Mar 2011 06:39:03 -0700 (PDT) Received: by 10.231.165.149 with HTTP; Mon, 14 Mar 2011 06:39:03 -0700 (PDT) In-Reply-To: <4D7E0831.4060804@gmail.com> References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> Date: Mon, 14 Mar 2011 14:39:03 +0100 Message-ID: From: Mats Lindberg To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:39:04 -0000 Thank's Mark I did some investigation though and I can't spot the difference between 6.3 and 8.1 login.conf. --------------------------------------- Script started on Mon Mar 14 14:46:37 2011 fspa1# uname -a FreeBSD fspa1 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:45:45 UTC 2008 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 fspa1# limit cputime unlimited filesize unlimited datasize 524288 kbytes stacksize 65536 kbytes coredumpsize unlimited memoryuse unlimited vmemoryuse unlimited descriptors 11095 memorylocked unlimited maxproc 5547 sbsize unlimited fspa1# dd if=/dev/zero of=/opt/whatever bs=1G count=1 dd: input buffer: Cannot allocate memory fspa1# exit exit Script done on Mon Mar 14 14:47:35 2011 ----------------------------------- Script started on Mon Mar 14 13:09:14 2011 fspa2# uname -a FreeBSD fspa2 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Mar 8 14:53:14 UTC 2011 root@vpc_a:/usr/obj/usr/src/sys/TESTING.4BSD i386 fspa2# limit cputime unlimited filesize unlimited datasize 524288 kbytes stacksize 65536 kbytes coredumpsize unlimited memoryuse unlimited vmemoryuse unlimited descriptors 11095 memorylocked unlimited maxproc 5547 sbsize unlimited swapsize unlimited fspa2# dd if=/dev/zero of=/opt/something bs=1G ----------------------------------------------- I'm logged in via rsh so now the system stop's responding - I have to kill my rlogin client. Both sessions in identical HW. If you're wondering about the kernel name The 8.1 kernel is a GENERIC were We've rebuilt it with the 4BSD scheduler just to test - We got same result with ULE scheduler. Any Ideas now? Coudl the 'dd' command be re-written (6.3->8.x) so that it does things very differently? /Mats 2011/3/14 Mark Tinguely > > You are running out of physical memory, there is no swap backstore and the > kernel is killing off other programs to claim memory. > > Compare the /etc/login.conf on both systems. I bet in the FreeBSD 6.3 > system, the memory limit is set to a limit (8M) and on the FreeBSD 8.1 it > is much higher or is "unlimited". With a set memory limit, the "dd" is > killed before the kernel starts killing off the other program. > > > On 3/14/2011 6:41 AM, Mats Lindberg wrote: > > No - not from what I understand > in the vmware it looks like a real disk device /dev/ad0s1e > in the nfsroot'ed system I actually have 'of=/opt/something' which is > definately to the nfs disk. > > > 2011/3/14 Mark Tinguely > >> On 3/14/2011 6:17 AM, Mats Lindberg wrote: >> >>> All >>> I am migrating from FreeBSD 6.3 to FreeBSD 8.1 And I have noticed some, >>> what >>> I think is, strange behaviour. >>> >>> In FreeBSD 6.3 when I do >>> >>>> swapoff -a >>>> dd if=/dev/zero of=/tmp/whatever bs=1G count=1 >>>> >>> I get something like "out of memory - killed" >>> >>> In FreeBSD 8.1 doing the same - processes around start to die, e.g. all >>> getty's are killed and finally devfs goes the same way. >>> >>> My target is diskless nfs mounted to a linux fileserver - hence no swap >>> partition >>> It does not seem to be relalted to the nfs root however - I get the same >>> behaviour running FBSD-8.1 in a VMWARE server session. >>> >>> Is this a new 'feature' of FBSD or just a bug? >>> Are there some sysctl's to set to 'really' turn of swapping. >>> >>> At one instance I also got a kernel panic saying 'page fault in kernel' >>> but >>> I'm having a hard time to repeat just that. >>> >>> regards >>> Mats >>> _______________________________________________ >>> 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" >>> >>> Do you have /tmp mounted on a memory filesystem? >> >> --Mark Tinguely >> >> > > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 13:43:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D23CF1065675 for ; Mon, 14 Mar 2011 13:43:49 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 952E48FC08 for ; Mon, 14 Mar 2011 13:43:49 +0000 (UTC) Received: by iyj12 with SMTP id 12so5861942iyj.13 for ; Mon, 14 Mar 2011 06:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/oIAmFgml0ej3QhgatRZBp7wTnsjFA42DA6gSNlXCcU=; b=bcmBw3AHdGBpAYqEAdanVl3XtWEg6833Itr1eeA4MlfEtlK2hgYDbJBqNlP5Wpqzf2 I4tAOauKResJrmdEhDEZVrQQjurjuqbDFvUwzeDJyRSGygkO0XcJIvI/eH49z5BFLbtn X5rRc7EFsMQyK+8XvkSt6ztGBQ4XYLobgFaT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B0V86OtAdsXxJnPNazfIUQnhppPqDFJD50jrI/2Uukh1ixfmqYPNf4xfc5IZ6v+j7f q6unh83PzPRnznVS+KPlsX56fNGRT6DVO6jr3D2cun+tqsOcYDlOQHjZ+SRbbMcwFVPO 9bWGm9vW/oP45p9JZOWG3N4Xv1xGGqLhheUDE= MIME-Version: 1.0 Received: by 10.231.53.76 with SMTP id l12mr9434185ibg.119.1300110228854; Mon, 14 Mar 2011 06:43:48 -0700 (PDT) Received: by 10.231.165.149 with HTTP; Mon, 14 Mar 2011 06:43:48 -0700 (PDT) In-Reply-To: <4D7E0831.4060804@gmail.com> References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> Date: Mon, 14 Mar 2011 14:43:48 +0100 Message-ID: From: Mats Lindberg To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:43:49 -0000 Hi again, just spotted the limit >>> swapsize unlimited I'll try to reset it and see what happens... 2011/3/14 Mark Tinguely > > You are running out of physical memory, there is no swap backstore and the > kernel is killing off other programs to claim memory. > > Compare the /etc/login.conf on both systems. I bet in the FreeBSD 6.3 > system, the memory limit is set to a limit (8M) and on the FreeBSD 8.1 it > is much higher or is "unlimited". With a set memory limit, the "dd" is > killed before the kernel starts killing off the other program. > > > On 3/14/2011 6:41 AM, Mats Lindberg wrote: > > No - not from what I understand > in the vmware it looks like a real disk device /dev/ad0s1e > in the nfsroot'ed system I actually have 'of=/opt/something' which is > definately to the nfs disk. > > > 2011/3/14 Mark Tinguely > >> On 3/14/2011 6:17 AM, Mats Lindberg wrote: >> >>> All >>> I am migrating from FreeBSD 6.3 to FreeBSD 8.1 And I have noticed some, >>> what >>> I think is, strange behaviour. >>> >>> In FreeBSD 6.3 when I do >>> >>>> swapoff -a >>>> dd if=/dev/zero of=/tmp/whatever bs=1G count=1 >>>> >>> I get something like "out of memory - killed" >>> >>> In FreeBSD 8.1 doing the same - processes around start to die, e.g. all >>> getty's are killed and finally devfs goes the same way. >>> >>> My target is diskless nfs mounted to a linux fileserver - hence no swap >>> partition >>> It does not seem to be relalted to the nfs root however - I get the same >>> behaviour running FBSD-8.1 in a VMWARE server session. >>> >>> Is this a new 'feature' of FBSD or just a bug? >>> Are there some sysctl's to set to 'really' turn of swapping. >>> >>> At one instance I also got a kernel panic saying 'page fault in kernel' >>> but >>> I'm having a hard time to repeat just that. >>> >>> regards >>> Mats >>> _______________________________________________ >>> 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" >>> >>> Do you have /tmp mounted on a memory filesystem? >> >> --Mark Tinguely >> >> > > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 14 15:59:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4925E1065673 for ; Mon, 14 Mar 2011 15:59:06 +0000 (UTC) (envelope-from ravi.murty@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE4E98FC0A for ; Mon, 14 Mar 2011 15:59:05 +0000 (UTC) Received: by bwz12 with SMTP id 12so5078710bwz.13 for ; Mon, 14 Mar 2011 08:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JFPvkwObzSFBXKn1wEqMkOpryQ1zD/C83amZZc5vxvo=; b=YgBgfnjmVH9OYpJQeR5FTTjJGtr3z+1+sJkOK7ewloJ7JWNrbDof3W7Xz4XF5yYDJI K3TMxXg5H0HSENDvjtHqTezuCEnwszI21/WtUPmpDp5Lt4lU3QywfPtOz6XO4/R9rmZu BlFZbozPZj9VO3C1UprAZVJueDTbckOVgMfJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aq9zIH2UwSbr+im6XfeUTlygfHEc/7E1PVmIn6B+LyN+muTCjv9e3LONFvDuVmoUvQ wtoVTF9HLHe4YhFvykZmzayGUdm4fde/QQ+OZf7tILHukDW+iqcQTkTW1d2yP2h6Ur7T hV5yQLkeEMphgejInewMpqCHJ9fo2cJJk02t8= MIME-Version: 1.0 Received: by 10.204.29.21 with SMTP id o21mr5468501bkc.97.1300118344574; Mon, 14 Mar 2011 08:59:04 -0700 (PDT) Received: by 10.204.117.193 with HTTP; Mon, 14 Mar 2011 08:59:04 -0700 (PDT) In-Reply-To: <20110314090318.GG78089@deviant.kiev.zoral.com.ua> References: <201103141230.49277.erich@alogreentechnologies.com> <20110314090318.GG78089@deviant.kiev.zoral.com.ua> Date: Mon, 14 Mar 2011 08:59:04 -0700 Message-ID: From: Ravi Murty To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-hackers@freebsd.org" , Erich Dollansky Subject: Re: SIGSTOP and SIGKILL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:59:06 -0000 I haven't tried sending a SIGCONT after this state. I see that one thread of the process has SIGSTOP still on its signal list, the SIGKILL is cleared because that's what the process was trying to do when it got caught and stopped instead. Before this happens, SIGCONT seems to be able to bring the threads back out of stopped state without any problems. Ravi On Mon, Mar 14, 2011 at 2:03 AM, Kostik Belousov wrote: > On Sun, Mar 13, 2011 at 11:30:00PM -0700, Ravi Murty wrote: > > I haven't, are there specific improvements in this area of the kernel? > First, the 8.2, compared to 8.0, changed the mechanism of delivering > the process-global signal to a thread. Now, the thread to deliver is > selected at the moment of delivery, instead of the moment of post. > This was done to close a race where either thread changed signal mask > after post, or exited after post, causing signal be undefinitely > delayed or ignored, respectively. > > Second, 8.2 less often stops the threads in the sleep state, more often > trying to move the thread to safer user<->kernel boundary, to take a stop. > Sleeping thread might indicate the unsafe sleep (from the POV of stopping) > by using PBDRY flag to msleep. > > Both the changes are not directly address the behaviour you described, > but they are explicitely in the area of your interest. > > BTW, it is not clear to me, does the process in the state as you > described, able to unwind from the stop state using SIGCONT ? I.e., > is it 'weird but recoverable' state, or is it 'weird and unrecoverable' > state ? > > > > On Mar 13, 2011, at 10:30 PM, Erich Dollansky < > erich@alogreentechnologies.com> wrote: > > > > > Hi, > > > > > > On Monday 14 March 2011 11:41:21 Ravi Murty wrote: > > > > > >> > > >> Any good solutions to this problem? > > > > > > did you try your program on 8.2? > > > > > > Erich > > _______________________________________________ > > 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 Mar 15 12:09:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53D97106564A for ; Tue, 15 Mar 2011 12:09:29 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 16F5A8FC16 for ; Tue, 15 Mar 2011 12:09:28 +0000 (UTC) Received: by yie12 with SMTP id 12so226319yie.13 for ; Tue, 15 Mar 2011 05:09:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.23.17 with SMTP id 17mr4541179agw.147.1300189179808; Tue, 15 Mar 2011 04:39:39 -0700 (PDT) Received: by 10.90.66.13 with HTTP; Tue, 15 Mar 2011 04:39:39 -0700 (PDT) X-Originating-IP: [95.108.170.139] Date: Tue, 15 Mar 2011 14:39:39 +0300 Message-ID: From: Andrey Zonov To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 15 Mar 2011 12:23:55 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: segfault in libz's longest_match() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 12:09:29 -0000 Hi, After updating to svn://svn.freebsd.org/base/stable/8@215508, some python scripts have started getting segfault. I've made coredump and found that problem in libz's function longest_match(). I think my problem is simmilar to PR http://www.freebsd.org/cgi/query-pr.cgi?pr=154073. Does anybody know what's going on? PS backtrace looks like this: (gdb) bt #0 0x00000000341552a6 in longest_match () from /lib/libz.so.5 #1 0x0000000034154230 in deflateParams () from /lib/libz.so.5 #2 0x000000003415370c in deflate () from /lib/libz.so.5 #3 0x000000003436653d in PyZlib_objcompress () from /usr/local/lib/python2.6/lib-dynload/zlib.so #4 0x000000000047d2ed in PyEval_EvalFrameEx () #5 0x000000000047e194 in PyEval_EvalFrameEx () #6 0x000000000047eb41 in PyEval_EvalCodeEx () #7 0x000000000047c95b in PyEval_EvalFrameEx () #8 0x000000000047eb41 in PyEval_EvalCodeEx () #9 0x000000000047c95b in PyEval_EvalFrameEx () #10 0x000000000047e194 in PyEval_EvalFrameEx () #11 0x000000000047e194 in PyEval_EvalFrameEx () #12 0x000000000047eb41 in PyEval_EvalCodeEx () #13 0x00000000004c839c in PyClassMethod_New () #14 0x0000000000417edd in PyObject_Call () #15 0x000000000047b08b in PyEval_EvalFrameEx () #16 0x000000000047e194 in PyEval_EvalFrameEx () #17 0x000000000047e194 in PyEval_EvalFrameEx () #18 0x000000000047eb41 in PyEval_EvalCodeEx () #19 0x00000000004c829d in PyClassMethod_New () #20 0x0000000000417edd in PyObject_Call () #21 0x000000000047b08b in PyEval_EvalFrameEx () #22 0x000000000047e194 in PyEval_EvalFrameEx () #23 0x000000000047e194 in PyEval_EvalFrameEx () #24 0x000000000047e194 in PyEval_EvalFrameEx () #25 0x000000000047e194 in PyEval_EvalFrameEx () #26 0x000000000047e194 in PyEval_EvalFrameEx () #27 0x000000000047eb41 in PyEval_EvalCodeEx () #28 0x00000000004c839c in PyClassMethod_New () #29 0x0000000000417edd in PyObject_Call () #30 0x000000000047b08b in PyEval_EvalFrameEx () #31 0x000000000047eb41 in PyEval_EvalCodeEx () #32 0x00000000004c839c in PyClassMethod_New () #33 0x0000000000417edd in PyObject_Call () #34 0x000000000047b08b in PyEval_EvalFrameEx () #35 0x000000000047eb41 in PyEval_EvalCodeEx () #36 0x00000000004c839c in PyClassMethod_New () #37 0x0000000000417edd in PyObject_Call () #38 0x000000000047b08b in PyEval_EvalFrameEx () #39 0x000000000047eb41 in PyEval_EvalCodeEx () #40 0x00000000004c839c in PyClassMethod_New () #41 0x0000000000417edd in PyObject_Call () #42 0x000000000047b08b in PyEval_EvalFrameEx () #43 0x000000000047eb41 in PyEval_EvalCodeEx () #44 0x000000000047c95b in PyEval_EvalFrameEx () #45 0x000000000047e194 in PyEval_EvalFrameEx () #46 0x000000000047e194 in PyEval_EvalFrameEx () #47 0x000000000047eb41 in PyEval_EvalCodeEx () #48 0x000000000047c95b in PyEval_EvalFrameEx () #49 0x000000000047eb41 in PyEval_EvalCodeEx () #50 0x000000000047ec22 in PyEval_EvalCode () #51 0x00000000004984b2 in Py_CompileString () #52 0x0000000000498586 in PyRun_FileExFlags () #53 0x0000000000499a0f in PyRun_SimpleFileExFlags () #54 0x0000000000413de3 in Py_Main () #55 0x00000000004131fa in main () (gdb) info threads * 1 Thread 32e041c0 (LWP 101629) 0x00000000341552a6 in longest_match () from /lib/libz.so.5 -- Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 15:23:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABCB41065672; Wed, 16 Mar 2011 15:23:13 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 921378FC17; Wed, 16 Mar 2011 15:23:13 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p2GFJcmt067202; Wed, 16 Mar 2011 08:19:38 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4D80D5E0.5080302@rawbw.com> Date: Wed, 16 Mar 2011 08:23:12 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: David Xu References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> In-Reply-To: <4D6B01DB.9090909@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 15:23:13 -0000 On 02/27/2011 18:00, David Xu wrote: > I think in normal case, pthread_cond_signal will wake up one thread, > but other events for example, UNIX signal and fork() may interrupt > a thread sleeping in kernel, and cause pthread_cond_wait to return > to userland, this is called spurious wakeup, and other events, I > can not think of yet, but I believe they exist. > Does this mean that pthread_cond_signal can also return EINTR? This isn't in pthread_cond_signal(3) either. Is this the case that all system calls should be assumed to be able to return EINTR or only those that have EINTR in their man pages? Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 17:25:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 515BC106567C for ; Wed, 16 Mar 2011 17:25:48 +0000 (UTC) (envelope-from tdamas@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1026F8FC2B for ; Wed, 16 Mar 2011 17:25:47 +0000 (UTC) Received: by vxc34 with SMTP id 34so2086635vxc.13 for ; Wed, 16 Mar 2011 10:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=IVvUcDAgsbm88aVG3S2Z0WnKloPr//GYrF1tbVXNmKk=; b=nFrtp/h3uDOAtrUA0Ku8iKa9qrsUy7iHPlr3kO5+bXNu9a9klUdzq0L0oIF5Lv/vjD 9U8vR9WzlUypRDLvUBbL8fkqgvUXv0B5Tc+29gzWr3WpyRyjRjmNk4RxPXD0uYbiX/jt nJXD8Sfu5RXpYuHfjJoFFWgiGDVaElstlF7bk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Dcwc9dmGq8v6ZBPupb63EKg1XPS6VmRVspJFcyne5VRyugWM4eypr1OH+SYEbYz75M 7zSafSBjL2/kHYz3wSJiw+0wDokCgyWiNOz6elIfmZuLgKWuIrSxK2HsxvFCDobbXwCX fRLRjezDn0u4K10ruD3ZxFQKTkFJZlGtT4dzQ= Received: by 10.52.167.196 with SMTP id zq4mr240621vdb.306.1300294964141; Wed, 16 Mar 2011 10:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.99.16 with HTTP; Wed, 16 Mar 2011 10:02:24 -0700 (PDT) From: Thiago Damas Date: Wed, 16 Mar 2011 14:02:24 -0300 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 17:25:48 -0000 Hi, without procfs, there is a way to get usertime and systime from a running process? Thiago From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 17:39:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B91991065673 for ; Wed, 16 Mar 2011 17:39:26 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id 95EEB8FC15 for ; Wed, 16 Mar 2011 17:39:26 +0000 (UTC) Received: from [192.82.228.128] (port=52049) by postoffice.vicor.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1PzuhC-0003Ah-LN; Wed, 16 Mar 2011 10:39:44 -0700 From: Devin Teske To: Thiago Damas In-Reply-To: References: Organization: VICOR, Inc. Date: Wed, 16 Mar 2011 17:39:01 +0000 Message-ID: <1300297142.47040.36.camel@dt.vicor.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 X-Scan-Signature: 686168b083bebe0229d0cf78d78c0aff X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset="cp1252" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 17:39:26 -0000 On Wed, 2011-03-16 at 14:02 -0300, Thiago Damas wrote: > Hi, > without procfs, there is a way to get usertime and systime from a > running process? > Maybe: ps axwwwo pid,time,command According to ps(1): time ... "accumulated cpu time, user + system" Unfortunately, I'm not able to find a way to get user time separate from system time ("time" -- aka "cputime" -- only gives combined "user" plus "system" time). > Thiago > _______________________________________________ > 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" -- -- Cheers, Devin Teske -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ L ++++$ E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b +>++ DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ Learn about the "Geek Code": http://www.geekcode.com/ -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 18:09:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2DF1106566C for ; Wed, 16 Mar 2011 18:09:48 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id BF79B8FC1D for ; Wed, 16 Mar 2011 18:09:47 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p2GHuF1q098710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 12:56:16 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id p2GHuFdL046049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 12:56:15 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.4/Submit) id p2GHuFJN046048; Wed, 16 Mar 2011 12:56:15 -0500 (CDT) (envelope-from dan) Date: Wed, 16 Mar 2011 12:56:14 -0500 From: Dan Nelson To: Thiago Damas Message-ID: <20110316175614.GB44561@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.2-PRERELEASE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Wed, 16 Mar 2011 12:56:16 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-hackers@freebsd.org Subject: Re: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 18:09:49 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Mar 16), Thiago Damas said: > Hi, > without procfs, there is a way to get usertime and systime from a > running process? Try applying the attached patch to ps. I've had it for a while but never submitted a PR. Heh. I've had it for a very long time. http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html -- Dan Nelson dnelson@allantgroup.com --ZGiS0Q5IWpPtfppv Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ps.diff" Index: ps.1 =================================================================== --- ps.1 (revision 219700) +++ ps.1 (working copy) @@ -587,6 +587,8 @@ symbolic process state (alias saved gid from a setgid executable .It Cm svuid saved UID from a setuid executable +.It Cm systime +accumulated system CPU time .It Cm tdaddr thread address .It Cm tdev @@ -617,6 +619,8 @@ scheduling priority on return from system call (al .Cm usrpri ) .It Cm user user name (from UID) +.It Cm usertime +accumulated user CPU time .It Cm vsz virtual size in Kbytes (alias .Cm vsize ) Index: keyword.c =================================================================== --- keyword.c (revision 219700) +++ keyword.c (working copy) @@ -186,6 +186,7 @@ static VAR var[] = { UINT, UIDFMT, 0}, {"svuid", "SVUID", NULL, 0, kvar, NULL, UIDLEN, KOFF(ki_svuid), UINT, UIDFMT, 0}, + {"systime", "SYSTIME", NULL, USER, systime, NULL, 9, 0, CHAR, NULL, 0}, {"tdaddr", "TDADDR", NULL, 0, kvar, NULL, sizeof(void *) * 2, KOFF(ki_tdaddr), KPTR, "lx", 0}, {"tdev", "TDEV", NULL, 0, tdev, NULL, 5, 0, CHAR, NULL, 0}, @@ -207,6 +208,7 @@ static VAR var[] = { KOFF(ki_paddr), KPTR, "lx", 0}, {"user", "USER", NULL, LJUST|DSIZ, uname, s_uname, USERLEN, 0, CHAR, NULL, 0}, + {"usertime", "USERTIME", NULL, USER, usertime, NULL, 9, 0, CHAR, NULL, 0}, {"usrpri", "", "upr", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"vsize", "", "vsz", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"vsz", "VSZ", NULL, 0, vsize, NULL, 5, 0, CHAR, NULL, 0}, Index: extern.h =================================================================== --- extern.h (revision 219700) +++ extern.h (working copy) @@ -79,12 +79,14 @@ int s_uname(KINFO *); void showkey(void); void started(KINFO *, VARENT *); void state(KINFO *, VARENT *); +void systime(KINFO *, VARENT *); void tdev(KINFO *, VARENT *); void tdnam(KINFO *, VARENT *); void tname(KINFO *, VARENT *); void ucomm(KINFO *, VARENT *); void uname(KINFO *, VARENT *); void upr(KINFO *, VARENT *); +void usertime(KINFO *, VARENT *); void vsize(KINFO *, VARENT *); void wchan(KINFO *, VARENT *); __END_DECLS Index: print.c =================================================================== --- print.c (revision 219700) +++ print.c (working copy) @@ -588,6 +588,79 @@ cputime(KINFO *k, VARENT *ve) } void +systime(KINFO *k, VARENT *ve) +{ + VAR *v; + long secs; + long psecs; /* "parts" of a second. first micro, then centi */ + char obuff[128]; + static char decimal_point; + + if (decimal_point == '\0') + decimal_point = localeconv()->decimal_point[0]; + v = ve->var; + if (!k->ki_valid) { + secs = 0; + psecs = 0; + } else { + /* + * This counts time spent handling interrupts. We could + * fix this, but it is not 100% trivial (and interrupt + * time fractions only work on the sparc anyway). XXX + */ + secs = k->ki_p->ki_rusage.ru_stime.tv_sec; + psecs = k->ki_p->ki_rusage.ru_stime.tv_usec; + if (sumrusage) { + secs += k->ki_p->ki_childstime.tv_sec; + psecs += k->ki_p->ki_childstime.tv_usec; + } + /* + * round and scale to 100's + */ + psecs = (psecs + 5000) / 10000; + secs += psecs / 100; + psecs = psecs % 100; + } + (void)snprintf(obuff, sizeof(obuff), "%3ld:%02ld%c%02ld", + secs / 60, secs % 60, decimal_point, psecs); + (void)printf("%*s", v->width, obuff); +} + +void +usertime(KINFO *k, VARENT *ve) +{ + VAR *v; + long secs; + long psecs; /* "parts" of a second. first micro, then centi */ + char obuff[128]; + static char decimal_point; + + if (decimal_point == '\0') + decimal_point = localeconv()->decimal_point[0]; + v = ve->var; + if (!k->ki_valid) { + secs = 0; + psecs = 0; + } else { + secs = k->ki_p->ki_rusage.ru_utime.tv_sec; + psecs = k->ki_p->ki_rusage.ru_utime.tv_usec; + if (sumrusage) { + secs += k->ki_p->ki_childutime.tv_sec; + psecs += k->ki_p->ki_childutime.tv_usec; + } + /* + * round and scale to 100's + */ + psecs = (psecs + 5000) / 10000; + secs += psecs / 100; + psecs = psecs % 100; + } + (void)snprintf(obuff, sizeof(obuff), "%3ld:%02ld%c%02ld", + secs / 60, secs % 60, decimal_point, psecs); + (void)printf("%*s", v->width, obuff); +} + +void elapsed(KINFO *k, VARENT *ve) { VAR *v; --ZGiS0Q5IWpPtfppv-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 19:23:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B836F106566B for ; Wed, 16 Mar 2011 19:23:33 +0000 (UTC) (envelope-from tdamas@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1C48FC17 for ; Wed, 16 Mar 2011 19:23:33 +0000 (UTC) Received: by vxc34 with SMTP id 34so2222094vxc.13 for ; Wed, 16 Mar 2011 12:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=Lyt3alXPV+JhEhBMR72NxNsZMm47tuUQSjzEM7tsFZs=; b=I6m8bfmtCWK69mAcGXP/eAoJa73gsWdmgTnsSDDp/FYp3ctA2uURnd3pNuMxRlcAST R2VsI59Q1JTdBhYY30opGj1So2VlEpEjosNdxL2Y/Pyozq5Beqv7mxZIfrQawStEOGpC bl9n92GCDLgkSpxQGXBMwTRMoTmb+5IMOUr7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=TA/O8eaHZ5WWvEAYOQymAWPaOVY6pwVPYa0TbZvaDpKvfPY2Y43luqoF0KHFB85/RS bMb+48oN4ksiyAn8J5n+noZXQ0Pk+Uy/0uXFsZ7wMIhmLzKJK0pKwpzypBHw/xey4EKy FTXLEE0NYcSyad+BAyBwv+r7HF/Tt5jt8zpSI= Received: by 10.52.160.38 with SMTP id xh6mr553318vdb.186.1300303412159; Wed, 16 Mar 2011 12:23:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.99.16 with HTTP; Wed, 16 Mar 2011 12:23:12 -0700 (PDT) In-Reply-To: References: <20110316175614.GB44561@dan.emsphone.com> From: Thiago Damas Date: Wed, 16 Mar 2011 16:23:12 -0300 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 19:23:33 -0000 Hi, the patch worked for me, using RELENG_8_2 Very thanks! Thiago 2011/3/16 Dan Nelson : > In the last episode (Mar 16), Thiago Damas said: >> =A0 Hi, >> =A0 without procfs, there is a way to get usertime and systime from a >> running process? > > Try applying the attached patch to ps. =A0I've had it for a while but nev= er > submitted a PR. > > Heh. I've had it for a very long time. > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html > > -- > =A0 =A0 =A0 =A0Dan Nelson > =A0 =A0 =A0 =A0dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 19:42:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E652E106575D for ; Wed, 16 Mar 2011 19:42:43 +0000 (UTC) (envelope-from dteske@vicor.com) Received: from postoffice.vicor.com (postoffice.vicor.com [69.26.56.53]) by mx1.freebsd.org (Postfix) with ESMTP id D1CD88FC18 for ; Wed, 16 Mar 2011 19:42:43 +0000 (UTC) Received: from [192.82.228.128] (port=52477) by postoffice.vicor.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1PzwcV-0003j8-SH; Wed, 16 Mar 2011 12:43:01 -0700 From: Devin Teske To: Dan Nelson In-Reply-To: <20110316175614.GB44561@dan.emsphone.com> References: <20110316175614.GB44561@dan.emsphone.com> Organization: VICOR, Inc. Date: Wed, 16 Mar 2011 19:42:22 +0000 Message-ID: <1300304542.47040.39.camel@dt.vicor.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 X-Scan-Signature: d1f2868b5d6833d1edc129686210a95a X-Scan-Host: postoffice.vicor.com Content-Type: text/plain; charset="cp1252" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Thiago Damas , freebsd-hackers@freebsd.org Subject: Re: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 19:42:44 -0000 On Wed, 2011-03-16 at 12:56 -0500, Dan Nelson wrote: > In the last episode (Mar 16), Thiago Damas said: > > Hi, > > without procfs, there is a way to get usertime and systime from a > > running process? > > Try applying the attached patch to ps. I've had it for a while but never > submitted a PR. > > Heh. I've had it for a very long time. > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html +1 useful. I'd like to see this committed. > > _______________________________________________ > 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" -- Cheers, Devin Teske -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ L ++++$ E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b +>++ DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ Learn about the "Geek Code": http://www.geekcode.com/ -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 20:11:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FF11065672 for ; Wed, 16 Mar 2011 20:11:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 436D98FC0A for ; Wed, 16 Mar 2011 20:11:56 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2GKBm6H018685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 22:11:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2GKBlqO064169; Wed, 16 Mar 2011 22:11:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2GKBlhv064168; Wed, 16 Mar 2011 22:11:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Mar 2011 22:11:47 +0200 From: Kostik Belousov To: Dan Nelson Message-ID: <20110316201147.GS78089@deviant.kiev.zoral.com.ua> References: <20110316175614.GB44561@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wbPyWLaTzb4uthOk" Content-Disposition: inline In-Reply-To: <20110316175614.GB44561@dan.emsphone.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Thiago Damas , freebsd-hackers@freebsd.org Subject: Re: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 20:11:58 -0000 --wbPyWLaTzb4uthOk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2011 at 12:56:14PM -0500, Dan Nelson wrote: > In the last episode (Mar 16), Thiago Damas said: > > Hi, > > without procfs, there is a way to get usertime and systime from a > > running process? >=20 > Try applying the attached patch to ps. I've had it for a while but never > submitted a PR. >=20 > Heh. I've had it for a very long time.=20 > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html Yes, apparently, this is often requested feature. I dislike the copying of the existing code, sincere up to the comment that is not quite relevant (about interrupts in systime). I slightly reorganized the patch to reduce the copy/paste part of it. Do you have comments ? diff --git a/bin/ps/extern.h b/bin/ps/extern.h index faeeb19..eb1ede6 100644 --- a/bin/ps/extern.h +++ b/bin/ps/extern.h @@ -81,12 +81,14 @@ int s_uname(KINFO *); void showkey(void); void started(KINFO *, VARENT *); void state(KINFO *, VARENT *); +void systime(KINFO *, VARENT *); void tdev(KINFO *, VARENT *); void tdnam(KINFO *, VARENT *); void tname(KINFO *, VARENT *); void ucomm(KINFO *, VARENT *); void uname(KINFO *, VARENT *); void upr(KINFO *, VARENT *); +void usertime(KINFO *, VARENT *); void vsize(KINFO *, VARENT *); void wchan(KINFO *, VARENT *); __END_DECLS diff --git a/bin/ps/keyword.c b/bin/ps/keyword.c index 3bcc23b..09eb756 100644 --- a/bin/ps/keyword.c +++ b/bin/ps/keyword.c @@ -189,6 +189,7 @@ static VAR var[] =3D { UINT, UIDFMT, 0}, {"svuid", "SVUID", NULL, 0, kvar, NULL, UIDLEN, KOFF(ki_svuid), UINT, UIDFMT, 0}, + {"systime", "SYSTIME", NULL, USER, systime, NULL, 9, 0, CHAR, NULL, 0}, {"tdaddr", "TDADDR", NULL, 0, kvar, NULL, sizeof(void *) * 2, KOFF(ki_tdaddr), KPTR, "lx", 0}, {"tdev", "TDEV", NULL, 0, tdev, NULL, 5, 0, CHAR, NULL, 0}, @@ -210,6 +211,8 @@ static VAR var[] =3D { KOFF(ki_paddr), KPTR, "lx", 0}, {"user", "USER", NULL, LJUST|DSIZ, uname, s_uname, USERLEN, 0, CHAR, NULL, 0}, + {"usertime", "USERTIME", NULL, USER, usertime, NULL, 9, 0, CHAR, NULL, + 0}, {"usrpri", "", "upr", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"vsize", "", "vsz", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"vsz", "VSZ", NULL, 0, vsize, NULL, 6, 0, CHAR, NULL, 0}, diff --git a/bin/ps/print.c b/bin/ps/print.c index 46b979b..253793a 100644 --- a/bin/ps/print.c +++ b/bin/ps/print.c @@ -550,12 +550,11 @@ vsize(KINFO *k, VARENT *ve) (void)printf("%*lu", v->width, (u_long)(k->ki_p->ki_size / 1024)); } =20 -void -cputime(KINFO *k, VARENT *ve) +static void +printtime(KINFO *k, VARENT *ve, long secs, long psecs) +/* psecs is "parts" of a second. first micro, then centi */ { VAR *v; - long secs; - long psecs; /* "parts" of a second. first micro, then centi */ char obuff[128]; static char decimal_point; =20 @@ -566,20 +565,7 @@ cputime(KINFO *k, VARENT *ve) secs =3D 0; psecs =3D 0; } else { - /* - * This counts time spent handling interrupts. We could - * fix this, but it is not 100% trivial (and interrupt - * time fractions only work on the sparc anyway). XXX - */ - secs =3D k->ki_p->ki_runtime / 1000000; - psecs =3D k->ki_p->ki_runtime % 1000000; - if (sumrusage) { - secs +=3D k->ki_p->ki_childtime.tv_sec; - psecs +=3D k->ki_p->ki_childtime.tv_usec; - } - /* - * round and scale to 100's - */ + /* round and scale to 100's */ psecs =3D (psecs + 5000) / 10000; secs +=3D psecs / 100; psecs =3D psecs % 100; @@ -590,6 +576,53 @@ cputime(KINFO *k, VARENT *ve) } =20 void +cputime(KINFO *k, VARENT *ve) +{ + long secs, psecs; + + /* + * This counts time spent handling interrupts. We could + * fix this, but it is not 100% trivial (and interrupt + * time fractions only work on the sparc anyway). XXX + */ + secs =3D k->ki_p->ki_runtime / 1000000; + psecs =3D k->ki_p->ki_runtime % 1000000; + if (sumrusage) { + secs +=3D k->ki_p->ki_childtime.tv_sec; + psecs +=3D k->ki_p->ki_childtime.tv_usec; + } + printtime(k, ve, secs, psecs); +} + +void +systime(KINFO *k, VARENT *ve) +{ + long secs, psecs; + + secs =3D k->ki_p->ki_rusage.ru_stime.tv_sec; + psecs =3D k->ki_p->ki_rusage.ru_stime.tv_usec; + if (sumrusage) { + secs +=3D k->ki_p->ki_childstime.tv_sec; + psecs +=3D k->ki_p->ki_childstime.tv_usec; + } + printtime(k, ve, secs, psecs); +} + +void +usertime(KINFO *k, VARENT *ve) +{ + long secs, psecs; + + secs =3D k->ki_p->ki_rusage.ru_utime.tv_sec; + psecs =3D k->ki_p->ki_rusage.ru_utime.tv_usec; + if (sumrusage) { + secs +=3D k->ki_p->ki_childutime.tv_sec; + psecs +=3D k->ki_p->ki_childutime.tv_usec; + } + printtime(k, ve, secs, psecs); +} + +void elapsed(KINFO *k, VARENT *ve) { VAR *v; diff --git a/bin/ps/ps.1 b/bin/ps/ps.1 index 5ae7c54..6f5511f 100644 --- a/bin/ps/ps.1 +++ b/bin/ps/ps.1 @@ -29,7 +29,7 @@ .\" @(#)ps.1 8.3 (Berkeley) 4/18/94 .\" $FreeBSD$ .\" -.Dd March 5, 2011 +.Dd March 16, 2011 .Dt PS 1 .Os .Sh NAME @@ -596,6 +596,8 @@ symbolic process state (alias saved gid from a setgid executable .It Cm svuid saved UID from a setuid executable +.It Cm systime +accumulated system CPU time .It Cm tdaddr thread address .It Cm tdev @@ -626,6 +628,8 @@ scheduling priority on return from system call (alias .Cm usrpri ) .It Cm user user name (from UID) +.It Cm usertime +accumulated user CPU time .It Cm vsz virtual size in Kbytes (alias .Cm vsize ) --wbPyWLaTzb4uthOk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEUEARECAAYFAk2BGYMACgkQC3+MBN1Mb4g2sQCdHVCLMAgXCpSVOj9Gc403w75W jmUAl20kIdqocdv4f+n3KFaVXbLYXDo= =80yo -----END PGP SIGNATURE----- --wbPyWLaTzb4uthOk-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 20:37:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 543AB106564A for ; Wed, 16 Mar 2011 20:37:40 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 262548FC13 for ; Wed, 16 Mar 2011 20:37:39 +0000 (UTC) Received: by iyj12 with SMTP id 12so2441518iyj.13 for ; Wed, 16 Mar 2011 13:37:39 -0700 (PDT) Received: by 10.42.162.133 with SMTP id y5mr605527icx.309.1300305986982; Wed, 16 Mar 2011 13:06:26 -0700 (PDT) Received: from tech304 (supranet-tech.secure-on.net [66.170.8.18]) by mx.google.com with ESMTPS id c1sm123489ibe.66.2011.03.16.13.06.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2011 13:06:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org References: <20110316175614.GB44561@dan.emsphone.com> <1300304542.47040.39.camel@dt.vicor.com> Date: Wed, 16 Mar 2011 15:06:24 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <1300304542.47040.39.camel@dt.vicor.com> User-Agent: Opera Mail/11.10 (FreeBSD) Subject: Re: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 20:37:40 -0000 On Wed, 16 Mar 2011 14:42:22 -0500, Devin Teske wrote: > +1 useful. > I'd like to see this committed. Agreed. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 22:41:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8ECC106564A for ; Wed, 16 Mar 2011 22:41:23 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id B071F8FC0C for ; Wed, 16 Mar 2011 22:41:23 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p2GMfM9K025812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 17:41:22 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id p2GMfMwu016941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 17:41:22 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.4/Submit) id p2GMfLsv016940; Wed, 16 Mar 2011 17:41:21 -0500 (CDT) (envelope-from dan) Date: Wed, 16 Mar 2011 17:41:21 -0500 From: Dan Nelson To: Kostik Belousov Message-ID: <20110316224121.GC44561@dan.emsphone.com> References: <20110316175614.GB44561@dan.emsphone.com> <20110316201147.GS78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110316201147.GS78089@deviant.kiev.zoral.com.ua> X-OS: FreeBSD 8.2-PRERELEASE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Wed, 16 Mar 2011 17:41:22 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: Thiago Damas , freebsd-hackers@freebsd.org Subject: Re: usertime and systime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 22:41:24 -0000 In the last episode (Mar 16), Kostik Belousov said: > On Wed, Mar 16, 2011 at 12:56:14PM -0500, Dan Nelson wrote: > > In the last episode (Mar 16), Thiago Damas said: > > > Hi, > > > without procfs, there is a way to get usertime and systime from a > > > running process? > > > > Try applying the attached patch to ps. I've had it for a while but > > never submitted a PR. > > > > Heh. I've had it for a very long time. > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html > > Yes, apparently, this is often requested feature. > > I dislike the copying of the existing code, sincere up to the comment that > is not quite relevant (about interrupts in systime). I slightly > reorganized the patch to reduce the copy/paste part of it. > > Do you have comments ? I like it. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 17 01:54:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3BE1065673; Thu, 17 Mar 2011 01:54:07 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96A3B8FC12; Thu, 17 Mar 2011 01:54:07 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2H1s5xx023745; Thu, 17 Mar 2011 01:54:06 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4D8169BF.6090503@freebsd.org> Date: Thu, 17 Mar 2011 09:54:07 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110127 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yuri References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> In-Reply-To: <4D80D5E0.5080302@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 01:54:07 -0000 On 2011/03/16 23:23, Yuri wrote: > On 02/27/2011 18:00, David Xu wrote: >> I think in normal case, pthread_cond_signal will wake up one thread, >> but other events for example, UNIX signal and fork() may interrupt >> a thread sleeping in kernel, and cause pthread_cond_wait to return >> to userland, this is called spurious wakeup, and other events, I >> can not think of yet, but I believe they exist. >> > > Does this mean that pthread_cond_signal can also return EINTR? This > isn't in pthread_cond_signal(3) either. > No, it will return zero, returning EINTR is not allowed. > Is this the case that all system calls should be assumed to be able to > return EINTR or only those that have EINTR in their man pages? > > Yuri > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 17 02:21:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C22F1106564A for ; Thu, 17 Mar 2011 02:21:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2FBE08FC0A for ; Thu, 17 Mar 2011 02:21:34 +0000 (UTC) Received: by wyf23 with SMTP id 23so2496052wyf.13 for ; Wed, 16 Mar 2011 19:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b24KqvnzCJExZEUoM/fasCbkKId6Fkg1si3ONAGMfPs=; b=OvO3+Iudtfa+yimTcLOyVHHh8LGONdGZxtg5r0LvgppKQ8/W0Sd1QUNJwcpqFYExq3 FhcboQ361aeQIWlrv5Che78xQZ81CSOeJRfxIbkdBLSaET8T1U5+L5r0EoyUz9v91fVU XQvoa9WOyQXSoTLDZkQ5JFjY4zIgYAGrhx/lQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wnoku/TFv5rjjqk3ArKc+8weczc5IzL/9WxUMT8YKGD1wTl2lKb33OqQYiuAN4UgeH VLYieTrRpx/q3ldv/PUJ71vT6n5XTBSw7n4v+Lub4gJzLw1I2SY7NX/69p7DUDXYr7vB /iGEiL2WG9M5CZe8gDsUfpzZKZUuF6aSlaEAY= MIME-Version: 1.0 Received: by 10.216.230.99 with SMTP id i77mr664626weq.100.1300328457639; Wed, 16 Mar 2011 19:20:57 -0700 (PDT) Received: by 10.216.173.142 with HTTP; Wed, 16 Mar 2011 19:20:57 -0700 (PDT) In-Reply-To: <4D8169BF.6090503@freebsd.org> References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> <4D8169BF.6090503@freebsd.org> Date: Wed, 16 Mar 2011 19:20:57 -0700 Message-ID: From: Garrett Cooper To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Cc: Yuri , standards@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 02:21:35 -0000 On Wed, Mar 16, 2011 at 6:54 PM, David Xu wrote: > On 2011/03/16 23:23, Yuri wrote: >> On 02/27/2011 18:00, David Xu wrote: >>> I think in normal case, pthread_cond_signal will wake up one thread, >>> but other events for example, UNIX signal and fork() may interrupt >>> a thread sleeping in kernel, and cause pthread_cond_wait to return >>> to userland, this is called spurious wakeup, and other events, I >>> can not think of yet, but I believe they exist. >>> >> >> Does this mean that pthread_cond_signal can also return EINTR? This >> isn't in pthread_cond_signal(3) either. >> > > No, it will return zero, returning EINTR is not allowed. Adding some more context by adding the appropriate POSIX spec material... RETURN VALUE If successful, the pthread_cond_broadcast() and pthread_cond_signal() functions shall return zero; otherwise, an error number shall be returned to indicate the error. ERRORS The pthread_cond_broadcast() and pthread_cond_signal() function may fail if: [EINVAL] The value cond does not refer to an initialized condition variable. These functions shall not return an error code of [EINTR]. So yes, EINTR not being allowed is by design and this backs up what davidxu@ is stating above. Our manpage just doesn't explicitly call this requirement out, unlike a Linux manpage I dug up and the OpenGroup manpage. >> Is this the case that all system calls should be assumed to be able to >> return EINTR or only those that have EINTR in their man pages? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 17 14:57:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19403106566B for ; Thu, 17 Mar 2011 14:57:32 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD32E8FC19 for ; Thu, 17 Mar 2011 14:57:31 +0000 (UTC) Received: by gwb15 with SMTP id 15so1290016gwb.13 for ; Thu, 17 Mar 2011 07:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=wruRgswqjaK6Es0Obg3hiLdFeB0vU/Dk6BZ+9hX9RvA=; b=vDKXZjQza3v3EvlZyOuiROjk5QbhgtxpvaFq8jjOHXCfBSBdtrpFzSsmQLpH22wdIQ aLOKtUx5HbWHP4EOAgHu4dqKYeQ/JgpBE+r9WJXeNaOqA7GjV5l8E7SRa2icvWJwS8t/ iR1EixO+HuO5Aqq0nnecJtqScrLsT473l+0S0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=x//jRYn8ej1PeCR4QRdwkTKKXx4X5RNe7qc23ouW6ydnu2oA8zXQXLnFEjgCawyxFP PlSSiMOSghvP4WcoUnYGXPHv/c2Kx0ENQzW+R52YxbNIvJpMCgTIdYwaIm+j3XHcxO91 GagzM1Wp8o2gDmBmbo4N7gFcCR1TzZc0+hRpg= MIME-Version: 1.0 Received: by 10.150.32.11 with SMTP id f11mr1570684ybf.100.1300373850751; Thu, 17 Mar 2011 07:57:30 -0700 (PDT) Received: by 10.151.144.21 with HTTP; Thu, 17 Mar 2011 07:57:30 -0700 (PDT) Date: Thu, 17 Mar 2011 15:57:30 +0100 Message-ID: From: "Domagoj S." To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: BWN State with BCM4321 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 14:57:32 -0000 I need an insight, regarding my wifi card: I've found this on maillist freebsd-current: http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014782.html Which motivated me, to directly mail, writer of driver. ---- ME: Hello, How long until bwn(4) will work with: Broadcom 432AGN WiFi mini PCI-Express That is BCM4321 Currently I'm loosing my patience with: (I'm Seeker) http://forums.freebsd.org/showthread.php?t=9204&page=6 If you have some code for me to try? I use amd64 8.2 RC2 ---- No plan to add a code for PHY-N drivers. It'll be happened by others not me. :-) regards, Weongyo Jeong ---- ME: Can I hava a contact of those "others"? ;) ---- ME: Listen, after having a thought, I really thing that you shoud finalize this by adding a code for PHY-N drivers, thus making even my card able to work nativelly on FreeBSD. Because you already know that code, from inside out. New developer would first need to familiarize itself with all that code, before he would even start to code on PHY-N drivers. If you do it, it would be magnitudes faster and I also promise I will be actievlly available, to constantly test your code, on my laptop. If you add a code for PHY-N drivers, then I'll completelly ditch WinXP and transfer to FreeBSD. As ndis is unstable, I still must use WinXP via dulaboot, so I could write you this email. So, you are not just adding a code for PHY-N drivers, but you are also adding a new user to FreeBSD. ;) Think about it ... --- No reply ... So ..., what is going on with it? From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 17 16:29:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0E4E106566B; Thu, 17 Mar 2011 16:29:00 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7828FC0A; Thu, 17 Mar 2011 16:29:00 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p2HGPPum040853; Thu, 17 Mar 2011 09:25:25 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4D8236CB.5010000@rawbw.com> Date: Thu, 17 Mar 2011 09:28:59 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: Garrett Cooper References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> <4D8169BF.6090503@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, standards@freebsd.org, David Xu Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:29:00 -0000 On 03/16/2011 19:20, Garrett Cooper wrote: > So yes, EINTR not being allowed is by design and this backs up what > davidxu@ is stating above. Our manpage just doesn't explicitly call > this requirement out, unlike a Linux manpage I dug up and the > OpenGroup manpage. > I apologize for keeping asking, but David Xu mentioned before that signal can also be delivered at the same time and pthread_cond_signal will exit. Normally its EINTR (like for open(2)). But now you are saying that EINTR isn't allowed for pthread_cond_signal. So does this mean that signal can't be delivered during pthread_cond_signal, or it will just return 0? In the latter case, how can I distinguish signal delivery and successful return? Yuri From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 17 18:36:40 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1FD73106564A; Thu, 17 Mar 2011 18:36:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@FreeBSD.org Date: Thu, 17 Mar 2011 14:36:16 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_mSlgNMBF7XViY3W" Message-Id: <201103171436.22283.jkim@FreeBSD.org> Cc: Kostik Belousov , Bruce Evans , Maxim Dounin Subject: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:36:40 -0000 --Boundary-00=_mSlgNMBF7XViY3W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Both get_cyclecount(9) and cpu_ticks() do almost exactly the same thing now assuming set_cputicker() is called with a correct function before get_cyclecount() is used, which is true for x86, at least. The only difference is get_cyclecount() may be inlined but I don't see much gain from the current uses. Please review the patch. Note I didn't really remove get_cyclecount() just because some random third-party module may use it as it is a documented feature while cpu_ticks is an internal KPI. What do you think? Jung-uk Kim --Boundary-00=_mSlgNMBF7XViY3W Content-Type: text/plain; charset="iso-8859-1"; name="cpu_ticks.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cpu_ticks.diff" Index: sys/kern/kern_ktr.c =================================================================== --- sys/kern/kern_ktr.c (revision 219714) +++ sys/kern/kern_ktr.c (working copy) @@ -73,7 +73,7 @@ __FBSDID("$FreeBSD$"); #endif #ifndef KTR_TIME -#define KTR_TIME get_cyclecount() +#define KTR_TIME cpu_ticks() #endif #ifndef KTR_CPU Index: sys/kern/init_main.c =================================================================== --- sys/kern/init_main.c (revision 219714) +++ sys/kern/init_main.c (working copy) @@ -560,7 +560,7 @@ SYSINIT(p0init, SI_SUB_INTRINSIC, SI_ORDER_FIRST, static void proc0_post(void *dummy __unused) { - struct timespec ts; + struct bintime bt; struct proc *p; struct rusage ru; struct thread *td; @@ -590,8 +590,8 @@ proc0_post(void *dummy __unused) /* * Give the ``random'' number generator a thump. */ - nanotime(&ts); - srandom(ts.tv_sec ^ ts.tv_nsec); + bintime(&bt); + srandom(bt.sec ^ bt.frac); } SYSINIT(p0post, SI_SUB_INTRINSIC_POST, SI_ORDER_FIRST, proc0_post, NULL); @@ -601,10 +601,10 @@ random_init(void *dummy __unused) /* * After CPU has been started we have some randomness on most - * platforms via get_cyclecount(). For platforms that don't - * we will reseed random(9) in proc0_post() as well. + * platforms via cpu_ticks(). For platforms that don't we will + * reseed random(9) in proc0_post() as well. */ - srandom(get_cyclecount()); + srandom(cpu_ticks()); } SYSINIT(random, SI_SUB_RANDOM, SI_ORDER_FIRST, random_init, NULL); Index: sys/netinet/sctp_os_bsd.h =================================================================== --- sys/netinet/sctp_os_bsd.h (revision 219714) +++ sys/netinet/sctp_os_bsd.h (working copy) @@ -129,7 +129,7 @@ MALLOC_DECLARE(SCTP_M_MCORE); #if defined(SCTP_LOCAL_TRACE_BUF) -#define SCTP_GET_CYCLECOUNT get_cyclecount() +#define SCTP_GET_CYCLECOUNT cpu_ticks() #define SCTP_CTR6 sctp_log_trace #else Index: sys/dev/de/if_devar.h =================================================================== --- sys/dev/de/if_devar.h (revision 219714) +++ sys/dev/de/if_devar.h (working copy) @@ -903,7 +903,7 @@ typedef u_long tulip_cycle_t; static __inline tulip_cycle_t TULIP_PERFREAD(void) { - return (get_cyclecount()); + return (cpu_ticks()); } #define TULIP_PERFDIFF(s, f) ((f) - (s)) Index: sys/dev/random/randomdev_soft.c =================================================================== --- sys/dev/random/randomdev_soft.c (revision 219714) +++ sys/dev/random/randomdev_soft.c (working copy) @@ -353,8 +353,8 @@ random_yarrow_write(void *buf, int count) chunk = HARVESTSIZE; if (i + chunk >= count) chunk = (u_int)(count - i); - random_harvest_internal(get_cyclecount(), (char *)buf + i, - chunk, 0, 0, RANDOM_WRITE); + random_harvest_internal(cpu_ticks(), (char *)buf + i, chunk, + 0, 0, RANDOM_WRITE); } } Index: sys/dev/random/harvest.c =================================================================== --- sys/dev/random/harvest.c (revision 219714) +++ sys/dev/random/harvest.c (working copy) @@ -78,17 +78,16 @@ random_yarrow_deinit_harvester(void) * Implemented as in indirect call to allow non-inclusion of * the entropy device. * - * XXXRW: get_cyclecount() is cheap on most modern hardware, where cycle - * counters are built in, but on older hardware it will do a real time clock - * read which can be quite expensive. + * XXXRW: cpu_ticks() is cheap on most modern hardware, where cycle counters + * are built in, but on older hardware it will do a real time clock read + * which can be quite expensive. */ void random_harvest(void *entropy, u_int count, u_int bits, u_int frac, enum esource origin) { if (reap_func) - (*reap_func)(get_cyclecount(), entropy, count, bits, frac, - origin); + (*reap_func)(cpu_ticks(), entropy, count, bits, frac, origin); } /* Userland-visible version of read_random */ Index: sys/i386/include/cpu.h =================================================================== --- sys/i386/include/cpu.h (revision 219714) +++ sys/i386/include/cpu.h (working copy) @@ -39,7 +39,6 @@ /* * Definitions unique to i386 cpu support. */ -#include #include #include #include @@ -70,13 +69,8 @@ void swi_vm(void *); static __inline uint64_t get_cyclecount(void) { - struct bintime bt; - if (cpu_class == CPUCLASS_486) { - binuptime(&bt); - return ((uint64_t)bt.sec << 56 | bt.frac >> 8); - } - return (rdtsc()); + return (cpu_ticks()); } #endif --Boundary-00=_mSlgNMBF7XViY3W-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 17 18:23:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFD1106566B for ; Thu, 17 Mar 2011 18:23:32 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id EFF768FC13 for ; Thu, 17 Mar 2011 18:23:31 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p2HIMrlm001800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Mar 2011 11:23:31 -0700 (PDT) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Mar 2011 11:23:31 -0700 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Thu, 17 Mar 2011 19:25:29 +0000 Subject: USENIX NSDI '11 is just two weeks away X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:23:32 -0000 We're writing to remind you that the 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI '11) is just two weeks away. There's stil time! Register today and join us in Boston, MA, March 30 - April 1, 2011. http://www.usenix.org/nsdi11/progc This year's program includes 27 technical papers carefully selected out of 157 submissions. These high-quality papers represent a diverse range of hot research areas including data-intensive computing, energy and storage, debugging and correctness, and more. In addition, NSDI '11 will feature a poster session where attendees can discuss emerging ideas in networked systems design by talking with leading researchers who are introducing their ongoing work. Submissions are due March 20, 2011. Find out more at: http://www.usenix.org/events/nsdi11/activities.html#poster We look forward to seeing you in Boston for the latest innovative networked systems research. Sincerely, David G. Andersen, Carnegie Mellon University Sylvia Ratnasamy, Intel Labs Berkeley nsdi11chairs@usenix.org P.S. Don't miss these workshops, which will be co-located with NSDI '11 and will take place on Tuesday, March 29, 2011: -- 4th USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET '11) http://www.usenix.org/events/leet11/ -- Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE '11) http://www.usenix.org/events/hotice11/ ------------------------------------------------------------------------ 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI '11) March 30-April 1, 2011 Boston, MA, USA http://www.usenix.org/nsdi11/progc Sponsored by USENIX in cooperation with ACM SIGCOMM and ACM SIGOPS Early Bird Registration Deadline: March 7, 2011 ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 08:35:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EAE71065675 for ; Fri, 18 Mar 2011 08:35:24 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC7EE8FC12 for ; Fri, 18 Mar 2011 08:35:21 +0000 (UTC) Received: by fxm11 with SMTP id 11so4024686fxm.13 for ; Fri, 18 Mar 2011 01:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CPbVI6D5iihlYX+yRDHDKtGRfEQPclvpGQ8gr33fqN8=; b=kChjZkjOwBoF3zskmbD1V9cU0pAIDPM41VlGM75pElQIp7ynlm6CtVFnb0Di/HS7Wb +lsO7htTI9O2hSvYP4XwrIL3pxNKMyNX/BF8kyIvAR2eG4a4GGC3zPM2Qx13ayqNxV+l xWkcXBQMWs6xO+s5P9ODI259KKC9asdoo+l5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vUUrruCqjpkQkopNdtHZKzMqqwdJF011nP20zWhB6DmUE9QaJNWOzIZ3Z7dttfnDuX 5+6S+ZKbze4Mcn9vT+CSRsT/xZS9Vs2ioH60dGZXM3i8tYlfaKejhBq/D9aItEK6VJ9s N9AWU13p5I5uXH9G/I+18NJDg8lTM1nDG+RT4= MIME-Version: 1.0 Received: by 10.223.31.133 with SMTP id y5mr958135fac.7.1300437320803; Fri, 18 Mar 2011 01:35:20 -0700 (PDT) Received: by 10.223.100.16 with HTTP; Fri, 18 Mar 2011 01:35:20 -0700 (PDT) In-Reply-To: <4D7E0831.4060804@gmail.com> References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> Date: Fri, 18 Mar 2011 09:35:20 +0100 Message-ID: From: Mats Lindberg To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 08:35:24 -0000 So - after a while I've made some observations. My problem is actually connected to arp. My config is very static so basically I want to turn off arp requests. Somewhere in the startup scripts I did > sysctl -w net.link.ether.inet.max_age=2147483647 (max accepted value) Which on freebsd-6.x worked fine. In freebsd-8.1 this makes the kernel arp functionality go bezerk - probably an integer overflow somewhere. arp requests were sent countinously from my freebsd-8.1 node to others, flooding the network. I tried to lower this value and found that 500000000s works fine 1000000000s does not. 500000000s is OK to me so I won't try to narrow it down more. The reason I was suspecting swapping problems was that after a while with the flooding going on I got a kernel panic saying 'page fault', which I would guess is a another bug, but, with a sensible setting on the arp timeout the kernel panic does not show itself any longer. I've googled for my arp-setting problem but not found anything on it. So - maybe I'm the first to see this. Should I enter a bug report somewhere? I guess this forum is not the place. /Mats 2011/3/14 Mark Tinguely > > You are running out of physical memory, there is no swap backstore and the > kernel is killing off other programs to claim memory. > > Compare the /etc/login.conf on both systems. I bet in the FreeBSD 6.3 > system, the memory limit is set to a limit (8M) and on the FreeBSD 8.1 it > is much higher or is "unlimited". With a set memory limit, the "dd" is > killed before the kernel starts killing off the other program. > > > On 3/14/2011 6:41 AM, Mats Lindberg wrote: > > No - not from what I understand > in the vmware it looks like a real disk device /dev/ad0s1e > in the nfsroot'ed system I actually have 'of=/opt/something' which is > definately to the nfs disk. > > > 2011/3/14 Mark Tinguely > >> On 3/14/2011 6:17 AM, Mats Lindberg wrote: >> >>> All >>> I am migrating from FreeBSD 6.3 to FreeBSD 8.1 And I have noticed some, >>> what >>> I think is, strange behaviour. >>> >>> In FreeBSD 6.3 when I do >>> >>>> swapoff -a >>>> dd if=/dev/zero of=/tmp/whatever bs=1G count=1 >>>> >>> I get something like "out of memory - killed" >>> >>> In FreeBSD 8.1 doing the same - processes around start to die, e.g. all >>> getty's are killed and finally devfs goes the same way. >>> >>> My target is diskless nfs mounted to a linux fileserver - hence no swap >>> partition >>> It does not seem to be relalted to the nfs root however - I get the same >>> behaviour running FBSD-8.1 in a VMWARE server session. >>> >>> Is this a new 'feature' of FBSD or just a bug? >>> Are there some sysctl's to set to 'really' turn of swapping. >>> >>> At one instance I also got a kernel panic saying 'page fault in kernel' >>> but >>> I'm having a hard time to repeat just that. >>> >>> regards >>> Mats >>> _______________________________________________ >>> 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" >>> >>> Do you have /tmp mounted on a memory filesystem? >> >> --Mark Tinguely >> >> > > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 09:08:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B26A106564A for ; Fri, 18 Mar 2011 09:08:48 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id A984F8FC14 for ; Fri, 18 Mar 2011 09:08:47 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 4616A7303E; Fri, 18 Mar 2011 10:08:45 +0100 (CET) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 1F7377303C; Fri, 18 Mar 2011 10:08:34 +0100 (CET) Message-ID: <4D83210D.5070107@thedarkside.nl> Date: Fri, 18 Mar 2011 10:08:29 +0100 From: Pieter de Boer MIME-Version: 1.0 To: Mats Lindberg References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> In-Reply-To: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on aberdeen.thelostparadise.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:08:48 -0000 On 03/18/2011 09:35 AM, Mats Lindberg wrote: > So - after a while I've made some observations. My problem is > actually connected to arp. > > My config is very static so basically I want to turn off arp > requests. Somewhere in the startup scripts I did >> sysctl -w net.link.ether.inet.max_age=2147483647 (max accepted >> value) > Are you aware of ifconfig staticarp ? I can imagine that the kernel uses some resources for every outstanding arp request, meaning that if it's continually sending arp requests, it also will use a lot of such resources.. -- Pieter From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 10:05:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ACC0106567C for ; Fri, 18 Mar 2011 10:05:15 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D000C8FC19 for ; Fri, 18 Mar 2011 10:05:14 +0000 (UTC) Received: by fxm11 with SMTP id 11so4087408fxm.13 for ; Fri, 18 Mar 2011 03:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GWTFWtGcBJFz8VMpe3FWfGPbmq8Fc5KNbVH+k5t+Ze4=; b=q79lYy7LlepA/a3LIrCPxfdEeVWE7CFYuMTLSJIyCDXHqSiCfZKKI95e+G8ssMqDhf A+c9Jw/q5hEIMUXS7rb7D4ZrA0IBZlI4yg25KX4wi+x0dj2efT3qYD83XqN93zqB/ui8 wJAGqMQndBf9xfRPtDZ8JzqmyW1yA+bFcSBsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZxbIY3NhcELHOZ31xIo6Bo11iSzqMbpJKdfSFtkdNJCbnefsj22dvHIhR7UFlxKmEc ovyu0tI+NGWl5qpP7tmoePMnb9mjVcoAurry3yQjOWFWSi4BSapKk/3/1YzMYhI6Il05 Erid7pt+i9w3ZHezUI3PFWkex1QV7mSBoWd9U= MIME-Version: 1.0 Received: by 10.223.14.22 with SMTP id e22mr1027702faa.64.1300442623898; Fri, 18 Mar 2011 03:03:43 -0700 (PDT) Received: by 10.223.100.16 with HTTP; Fri, 18 Mar 2011 03:03:43 -0700 (PDT) In-Reply-To: <4D83210D.5070107@thedarkside.nl> References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> <4D83210D.5070107@thedarkside.nl> Date: Fri, 18 Mar 2011 11:03:43 +0100 Message-ID: From: Mats Lindberg To: Pieter de Boer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 10:05:15 -0000 No - I was not aware of this, I'll try it, thanks... /Mats 2011/3/18 Pieter de Boer > On 03/18/2011 09:35 AM, Mats Lindberg wrote: > > > So - after a while I've made some observations. My problem is > > actually connected to arp. > > > > My config is very static so basically I want to turn off arp > > requests. Somewhere in the startup scripts I did > >> sysctl -w net.link.ether.inet.max_age=2147483647 (max accepted > >> value) > > > Are you aware of ifconfig staticarp ? > > I can imagine that the kernel uses some resources for every > outstanding arp request, meaning that if it's continually sending arp > requests, it also will use a lot of such resources.. > > -- > Pieter > > > > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 08:10:04 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C09C106566B for ; Fri, 18 Mar 2011 08:10:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6357F8FC1B for ; Fri, 18 Mar 2011 08:10:03 +0000 (UTC) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2I6QwPg016405 for ; Fri, 18 Mar 2011 17:26:58 +1100 Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2I6QrQv018194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 17:26:54 +1100 Date: Fri, 18 Mar 2011 17:26:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jung-uk Kim In-Reply-To: <201103171436.22283.jkim@FreeBSD.org> Message-ID: <20110318162252.S984@besplex.bde.org> References: <201103171436.22283.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 18 Mar 2011 11:14:21 +0000 Cc: Kostik Belousov , freebsd-hackers@FreeBSD.org, Bruce Evans , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 08:10:04 -0000 On Thu, 17 Mar 2011, Jung-uk Kim wrote: > Both get_cyclecount(9) and cpu_ticks() do almost exactly the same > thing now assuming set_cputicker() is called with a correct function > before get_cyclecount() is used, which is true for x86, at least. > The only difference is get_cyclecount() may be inlined but I don't > see much gain from the current uses. > > Please review the patch. Note I didn't really remove get_cyclecount() > just because some random third-party module may use it as it is a > documented feature while cpu_ticks is an internal KPI. > > What do you think? I like this idea, but see some minor problems: - cpu_ticks() API needs to become more public and stable, and guarantee to use the ticker with the highest frequency - it is hard to see when set_cputicker() is called, but on i386 it is called very early so there seem to be no problems with the dummy timecounter. It is called from init_TSC() which is called from startrtclock() which is called from machdep.c:cpu_startup() just after the garbage "Good morning" comment which was originally just banal since it preceeded its code (the printf that prints the copyright message). The ordering of this is now highly obfuscated, and in fact there is now the following enormous amount of code between the printf and its comment: % enum sysinit_sub_id { % SI_SUB_DUMMY = 0x0000000, /* not executed; for linker*/ % SI_SUB_DONE = 0x0000001, /* processed*/ % SI_SUB_TUNABLES = 0x0700000, /* establish tunable values */ % SI_SUB_COPYRIGHT = 0x0800001, /* first use of console*/ ^^^^^^^^^ prints the copyright % SI_SUB_SETTINGS = 0x0880000, /* check and recheck settings */ % SI_SUB_MTX_POOL_STATIC = 0x0900000, /* static mutex pool */ % SI_SUB_LOCKMGR = 0x0980000, /* lockmgr locks */ % SI_SUB_VM = 0x1000000, /* virtual memory system init*/ % SI_SUB_KMEM = 0x1800000, /* kernel memory*/ % SI_SUB_KVM_RSRC = 0x1A00000, /* kvm operational limits*/ % SI_SUB_WITNESS = 0x1A80000, /* witness initialization */ % SI_SUB_MTX_POOL_DYNAMIC = 0x1AC0000, /* dynamic mutex pool */ % SI_SUB_LOCK = 0x1B00000, /* various locks */ % SI_SUB_EVENTHANDLER = 0x1C00000, /* eventhandler init */ % SI_SUB_VNET_PRELINK = 0x1E00000, /* vnet init before modules */ % SI_SUB_KLD = 0x2000000, /* KLD and module setup */ % SI_SUB_CPU = 0x2100000, /* CPU resource(s)*/ ^^^ calls cpu_startup() but there seem to be no slow operations (like device initialization) in there, so cpu_startup() seems to be called early enough. The function names for clock initialization are almost equally rotted: - the realtime clock was originally the i8254, and startrtclock() started it. Now startrtclock() doesn't touch either the the realtime clock (the timecounter) or the i8254. It only calls init_TSC(). This might as well be called directly. The i8254 is now initialized (only?) by i8254, which is called much earlier, from init386(), so that DELAY() works when called early from console drivers. The same care should be taken with initializing the TSC for early use, and would be essential if the i8254 support in DELAY() were removed. - the correct interface for attaching the realtime clock now seems to be cpu_initclocks(). This is now used for the TSC (init_TSC_tc()). But the i8254 is now attached as a timecounter in attimer_attach(). - set_cputicker() has various races and implementation bugs: - it has no visible locking. This may be safe when it is called at boot time. It is also called from tsc_levels_changed(). BTW, these calls still don't know about P-state invariance. They always pass the parameter saying that the ticker is variable. This despite the invariance variable being checked to lines after the call that passes a hard-coded for variance. - the call to set_cputicker() after machdep.tsc_freq changes the ticker freqency is missing. This is a feature if the ticker is variable, since the dynamic ticker calibration code can be more accurate than a fixed setting, and would undo any fixed setting. But this code is buggy... - set cputicker() has some design bugs. It assumes that the tick frequency is the same across all CPUs, but the TSC is per-CPU. I have an old SMP system with CPUs of different frequency that can demonstrate bugs from this. Bruce From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 12:51:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 624A91065673 for ; Fri, 18 Mar 2011 12:51:41 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 211348FC08 for ; Fri, 18 Mar 2011 12:51:40 +0000 (UTC) Received: by iwn33 with SMTP id 33so4641835iwn.13 for ; Fri, 18 Mar 2011 05:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bF6/tL735Aj+zcYZ1uDepnlSJOMbuSYzY8Cou1H0l8I=; b=ot7jqgoHQQPeXt+6KPXkBIxG29Jb05VVleAYrrmFGcBdERs+l4LSfMcoeFmxaK3j/8 xQNdU8DG4mh+zuwRuWDI2LnbDc5uMMl5fKXdqT/X64N04vHwf2SAItIWJH6ZYRS7ojMY f7f1rNoK24LFFqGRb5PDfXyIQHryJeCSkBzqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fF7tV8caknSiVOaHpWFks4j5UmuJ2fH9fr0cws1RjKjttsmds+X098+CoqL4VpU96o SK3/30ridT99p7XbT8SX574XV2sPHe3c+2GHgZ8/d0XCOnuDNRdbsY98vSdm5NGrOY8C FMlIn4rEqw19R41nLr7eMT2qolA+jMQPdESNs= Received: by 10.231.117.93 with SMTP id p29mr875217ibq.126.1300451136390; Fri, 18 Mar 2011 05:25:36 -0700 (PDT) Received: from [192.168.1.101] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id gy41sm291519ibb.56.2011.03.18.05.25.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Mar 2011 05:25:32 -0700 (PDT) Message-ID: <4D834F35.5030806@gmail.com> Date: Fri, 18 Mar 2011 07:25:25 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mats Lindberg References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 12:51:41 -0000 On 3/18/2011 3:35 AM, Mats Lindberg wrote: > So - after a while I've made some observations. > My problem is actually connected to arp. > > My config is very static so basically I want to turn off arp requests. > Somewhere in the startup scripts I did > > sysctl -w net.link.ether.inet.max_age=2147483647 (max accepted value) > Which on freebsd-6.x worked fine. > In freebsd-8.1 this makes the kernel arp functionality go bezerk - > probably an integer overflow somewhere. > arp requests were sent countinously from my freebsd-8.1 node to > others, flooding the network. > I tried to lower this value and found that 500000000s works fine > 1000000000s does not. 500000000s is OK to me so I won't try to narrow > it down more. > > The reason I was suspecting swapping problems was that after a while > with the flooding going on I got a kernel panic saying 'page fault', > which I would guess is a another bug, but, with a sensible setting on > the arp timeout the kernel panic does not show itself any longer. > > I've googled for my arp-setting problem but not found anything on it. > So - maybe I'm the first to see this. > Should I enter a bug report somewhere? > I guess this forum is not the place. > > /Mats > Did your HZ (timer interrupts per second) increase from 100 on FreeBSD-6 to 1000 on FreeBSD-8.1? This must be a 32 bit computer / OS because that variable is multiplied to hz: canceled = callout_reset(&la->la_timer, hz * V_arpt_keep, arptimer, la); and: #define callout_reset(c, on_tick, fn, arg) \ callout_reset_on((c), (on_tick), (fn), (arg), (c)->c_cpu) where: int callout_reset_on(struct callout *, int , void (*ftn)(void *), void *, int) I would guess that you are wrapping with 32 bit arithmetic to a small value. Both the hz==100 and hz==1000 will wrap to about the same number (a negative number). I did not look at the FreeBSD 6.x callout, but I think in the FreeBSD 8 callout, negative on_tick will be immediately called on the next tick.. A page fault panic is a kernel access to a non-mapped VA (a bad pointer). The panic message would have the VA and instruction address information. --Mark From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 13:56:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43990106566B; Fri, 18 Mar 2011 13:56:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AC78B8FC08; Fri, 18 Mar 2011 13:56:51 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2IDul5U037470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 15:56:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2IDul9E076434; Fri, 18 Mar 2011 15:56:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2IDul7M076433; Fri, 18 Mar 2011 15:56:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Mar 2011 15:56:47 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20110318135647.GY78089@deviant.kiev.zoral.com.ua> References: <201103171436.22283.jkim@FreeBSD.org> <20110318162252.S984@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+cM0fg6xnYQzCTTM" Content-Disposition: inline In-Reply-To: <20110318162252.S984@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Jung-uk Kim , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 13:56:52 -0000 --+cM0fg6xnYQzCTTM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote: ... > - set cputicker() has some design bugs. It assumes that the tick frequency > is the same across all CPUs, but the TSC is per-CPU. I have an old SMP > system with CPUs of different frequency that can demonstrate bugs from > this. We definitely do not support configurations with different models of CPUs in SMP, this is what Simmetric is about. Different as in frequency or stepping. --+cM0fg6xnYQzCTTM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2DZJ8ACgkQC3+MBN1Mb4jipACgzJaB/F9l5tXTRnNwuwWND5BF +TgAoIbACHkiEEe9YTG9PDm4Vw5tpaCp =NGa3 -----END PGP SIGNATURE----- --+cM0fg6xnYQzCTTM-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 15:17:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA34106564A for ; Fri, 18 Mar 2011 15:17:48 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF3F8FC0C for ; Fri, 18 Mar 2011 15:17:47 +0000 (UTC) Received: by fxm11 with SMTP id 11so4390698fxm.13 for ; Fri, 18 Mar 2011 08:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YAqoPDxI7+lsKt3lPSZl3G0stD1iYbiSlYOXObafbEA=; b=JQhZXPQ26P1CsUgh+mscwmsZKhoTzToX10o7ZdhtJd9/KNmcVE0/o3JjGo+/j8D3hs RRDqx45zu5RCv+Raddv81jJQ3Xf02vEfNLmYkotobEa7ZqDNJiFZcmt5cNKfDxb7oHUN Xxps9UIqdfheJWkPwOoWta1A6SgLrZdvdY+JY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vr9RojnZYR72gglVNMusIjM22ulGS0Z2DJCFf22cZ4BzH0QkVc4LNwEygmM4xEIztQ cTSQ6UVEDCC3SWQCJuraJaHiNiYeuuzkrSMtDkrwdQTaFTJFr6U+jDIgv0NlqNFY8K8H fnmWxenXOJanY3ZAtFMXgbnt41ZIqEFbuIFVs= MIME-Version: 1.0 Received: by 10.223.64.201 with SMTP id f9mr1381045fai.102.1300461457066; Fri, 18 Mar 2011 08:17:37 -0700 (PDT) Received: by 10.223.100.16 with HTTP; Fri, 18 Mar 2011 08:17:36 -0700 (PDT) In-Reply-To: References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> <4D834F35.5030806@gmail.com> Date: Fri, 18 Mar 2011 16:17:36 +0100 Message-ID: From: Mats Lindberg To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:17:48 -0000 ---------- Forwarded message ---------- From: Mats Lindberg Date: 2011/3/18 Subject: Re: FreeBSD 6 vs 8.1 To: Mark Tinguely 2011/3/18 Mark Tinguely > On 3/18/2011 3:35 AM, Mats Lindberg wrote: > >> So - after a while I've made some observations. >> My problem is actually connected to arp. >> >> My config is very static so basically I want to turn off arp requests. >> Somewhere in the startup scripts I did >> > sysctl -w net.link.ether.inet.max_age=2147483647 (max accepted value) >> Which on freebsd-6.x worked fine. >> In freebsd-8.1 this makes the kernel arp functionality go bezerk - >> probably an integer overflow somewhere. >> arp requests were sent countinously from my freebsd-8.1 node to others, >> flooding the network. >> I tried to lower this value and found that 500000000s works fine >> 1000000000s does not. 500000000s is OK to me so I won't try to narrow it >> down more. >> >> The reason I was suspecting swapping problems was that after a while with >> the flooding going on I got a kernel panic saying 'page fault', which I >> would guess is a another bug, but, with a sensible setting on the arp >> timeout the kernel panic does not show itself any longer. >> >> I've googled for my arp-setting problem but not found anything on it. So - >> maybe I'm the first to see this. >> Should I enter a bug report somewhere? >> I guess this forum is not the place. >> >> /Mats >> >> > Did your HZ (timer interrupts per second) increase from 100 on FreeBSD-6 to > 1000 on FreeBSD-8.1? This must be a 32 bit computer / OS because that > variable is multiplied to hz: > > canceled = callout_reset(&la->la_timer, > hz * V_arpt_keep, arptimer, la); > > and: > > #define callout_reset(c, on_tick, fn, arg) \ > callout_reset_on((c), (on_tick), (fn), (arg), (c)->c_cpu) > > where: > > int callout_reset_on(struct callout *, int , void (*ftn)(void *), void *, > int) > > I would guess that you are wrapping with 32 bit arithmetic to a small > value. Both the hz==100 and hz==1000 will wrap to about the same number (a > negative number). I did not look at the FreeBSD 6.x callout, but I think in > the FreeBSD 8 callout, negative on_tick will be immediately called on the > next tick.. > Yes I could imagine this is it. > > A page fault panic is a kernel access to a non-mapped VA (a bad pointer). > The panic message would have the VA and instruction address information. > > --Mark > Well, Both systems are i386 32bit On FreeBSD-6 I have: (GENERIC) kernel kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } On FreeBSD-8 I have:(Excluded some drivers from GENERIC kernel) kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } kern.hz: 1000 So same HZ -- seems the callout is implemented differently 6.x->8.1 For the kernel panic I get fault virtual address: 0x8 instruction pointer: 0x20:0xc0679ed7 current process: 0, (em0 taskq) I don't know anything about these numbers, or if you even did want to know. To me I get the feeling that this is connected to my arp problem, seems to be something in the em driver that is not handled at this high load. I'm quite happy now - my system has been up and running for the whole day - so I'll leave it at this - thanks /Mats From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 15:51:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3177106564A; Fri, 18 Mar 2011 15:51:43 +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 D904B8FC13; Fri, 18 Mar 2011 15:51:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA16767; Fri, 18 Mar 2011 17:51:28 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D837F7F.2060403@freebsd.org> Date: Fri, 18 Mar 2011 17:51:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kostik Belousov References: <201103171436.22283.jkim@FreeBSD.org> <20110318162252.S984@besplex.bde.org> <20110318135647.GY78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110318135647.GY78089@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jung-uk Kim , Bruce Evans , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:51:43 -0000 on 18/03/2011 15:56 Kostik Belousov said the following: > On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote: > ... >> - set cputicker() has some design bugs. It assumes that the tick frequency >> is the same across all CPUs, but the TSC is per-CPU. I have an old SMP >> system with CPUs of different frequency that can demonstrate bugs from >> this. > We definitely do not support configurations with different models of > CPUs in SMP, this is what Simmetric is about. Different as in frequency > or stepping. Are there any fundamental reasons for us to not support that configuration in situations where hardware and BIOS (in x86 case) happen to support it? I am personally more interested in non-uniform topologies like one package having two cores and another having four. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 16:15:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4071065670; Fri, 18 Mar 2011 16:15:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0248FC16; Fri, 18 Mar 2011 16:15:28 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2IGFOxb049492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 18:15:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2IGFOuM078066; Fri, 18 Mar 2011 18:15:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2IGFOPI078065; Fri, 18 Mar 2011 18:15:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Mar 2011 18:15:24 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20110318161524.GC78089@deviant.kiev.zoral.com.ua> References: <201103171436.22283.jkim@FreeBSD.org> <20110318162252.S984@besplex.bde.org> <20110318135647.GY78089@deviant.kiev.zoral.com.ua> <4D837F7F.2060403@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gL219CPYpMREpKpt" Content-Disposition: inline In-Reply-To: <4D837F7F.2060403@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Jung-uk Kim , Bruce Evans , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:15:29 -0000 --gL219CPYpMREpKpt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 18, 2011 at 05:51:27PM +0200, Andriy Gapon wrote: > on 18/03/2011 15:56 Kostik Belousov said the following: > > On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote: > > ... > >> - set cputicker() has some design bugs. It assumes that the tick freq= uency > >> is the same across all CPUs, but the TSC is per-CPU. I have an old = SMP > >> system with CPUs of different frequency that can demonstrate bugs fr= om > >> this. > > We definitely do not support configurations with different models of > > CPUs in SMP, this is what Simmetric is about. Different as in frequency > > or stepping. >=20 > Are there any fundamental reasons for us to not support that configuratio= n in > situations where hardware and BIOS (in x86 case) happen to support it? >=20 > I am personally more interested in non-uniform topologies like one packag= e having > two cores and another having four. We do not handle CPU errata/quirks individually per-core. I think that we assume that all cores have the same stepping and thus require the same workarounds, if any, as BSP. Also, I think tsc calibration is done only on BSP, but I may be wrong there. --gL219CPYpMREpKpt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2DhRwACgkQC3+MBN1Mb4jtmACguqAsvWYeXb6Y23NHLqnblNiC UMEAoIu/L8aaw1tE+X5gnCw0Ir3euF7i =QS5W -----END PGP SIGNATURE----- --gL219CPYpMREpKpt-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 16:04:58 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37ABD106564A; Fri, 18 Mar 2011 16:04:58 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id B17D08FC12; Fri, 18 Mar 2011 16:04:57 +0000 (UTC) Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2IG4rMg018681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Mar 2011 03:04:55 +1100 Date: Sat, 19 Mar 2011 03:04:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20110318135647.GY78089@deviant.kiev.zoral.com.ua> Message-ID: <20110319024813.N2581@besplex.bde.org> References: <201103171436.22283.jkim@FreeBSD.org> <20110318162252.S984@besplex.bde.org> <20110318135647.GY78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 18 Mar 2011 16:31:49 +0000 Cc: freebsd-hackers@FreeBSD.org, Jung-uk Kim , Bruce Evans , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:04:58 -0000 On Fri, 18 Mar 2011, Kostik Belousov wrote: > On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote: > ... >> - set cputicker() has some design bugs. It assumes that the tick frequency >> is the same across all CPUs, but the TSC is per-CPU. I have an old SMP >> system with CPUs of different frequency that can demonstrate bugs from >> this. > We definitely do not support configurations with different models of > CPUs in SMP, this is what Simmetric is about. Different as in frequency > or stepping. It worked before this bug was implemented. The TSC wasn't used so the O/S didn't notice the asymmetric frequencies directly, and the O/S also didn't care about this indirectly. Now there is even more asymmetry in core frequencies, with the hardware transiently slowing down or stopping cores independently, at least for cores in different packages. Ths O/S probably can't see this directly using TSCs since the technology that changes the core's frequencies probably comes with invariant TSCs, and the O/S shouldn't care about this indirectly just like before. Bruce From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 16:38:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8CF06106566C; Fri, 18 Mar 2011 16:38:25 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Kostik Belousov Date: Fri, 18 Mar 2011 12:38:11 -0400 User-Agent: KMail/1.6.2 References: <201103171436.22283.jkim@FreeBSD.org> <4D837F7F.2060403@freebsd.org> <20110318161524.GC78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110318161524.GC78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103181238.14793.jkim@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, Bruce Evans , Andriy Gapon , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:38:27 -0000 On Friday 18 March 2011 12:15 pm, Kostik Belousov wrote: > On Fri, Mar 18, 2011 at 05:51:27PM +0200, Andriy Gapon wrote: > > on 18/03/2011 15:56 Kostik Belousov said the following: > > > On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote: > > > ... > > > > > >> - set cputicker() has some design bugs. It assumes that the > > >> tick frequency is the same across all CPUs, but the TSC is > > >> per-CPU. I have an old SMP system with CPUs of different > > >> frequency that can demonstrate bugs from this. > > > > > > We definitely do not support configurations with different > > > models of CPUs in SMP, this is what Simmetric is about. > > > Different as in frequency or stepping. > > > > Are there any fundamental reasons for us to not support that > > configuration in situations where hardware and BIOS (in x86 case) > > happen to support it? > > > > I am personally more interested in non-uniform topologies like > > one package having two cores and another having four. > > We do not handle CPU errata/quirks individually per-core. I think > that we assume that all cores have the same stepping and thus > require the same workarounds, if any, as BSP. Also, I think tsc > calibration is done only on BSP, but I may be wrong there. Yeah, it is just sad but that's what we do now. Just for per-CPU ticker, however, it won't be too hard, though. Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 17:05:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D790F106566C; Fri, 18 Mar 2011 17:05:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5DCE38FC16; Fri, 18 Mar 2011 17:05:27 +0000 (UTC) Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2IH5No7010129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Mar 2011 04:05:24 +1100 Date: Sat, 19 Mar 2011 04:05:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20110319024813.N2581@besplex.bde.org> Message-ID: <20110319035138.H3038@besplex.bde.org> References: <201103171436.22283.jkim@FreeBSD.org> <20110318162252.S984@besplex.bde.org> <20110318135647.GY78089@deviant.kiev.zoral.com.ua> <20110319024813.N2581@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 18 Mar 2011 17:13:11 +0000 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, Jung-uk Kim , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:05:27 -0000 On Sat, 19 Mar 2011, Bruce Evans wrote: > On Fri, 18 Mar 2011, Kostik Belousov wrote: >> We definitely do not support configurations with different models of >> CPUs in SMP, this is what Simmetric is about. Different as in frequency >> or stepping. > > ... > Now there is even more asymmetry > in core frequencies, with the hardware transiently slowing down or > stopping cores independently, at least for cores in different packages. Also, with virtualization, the virtualizer cannot reasonably even provide an invariant TSC that runs at the same rate on all cores. It should provide an invariant TSC that claims to run at the same rate on all cores, but then the cores cannot run at the same rate except on average, since some of the cores will have to run the virtualizer some of the time, and it is unreasonable to distribute the overhead for this evenly except on average. Bruce From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 17:43:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50940106564A for ; Fri, 18 Mar 2011 17:43:59 +0000 (UTC) (envelope-from mats.w.lindberg@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF9488FC13 for ; Fri, 18 Mar 2011 17:43:58 +0000 (UTC) Received: by fxm11 with SMTP id 11so4555402fxm.13 for ; Fri, 18 Mar 2011 10:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ac9vevNLqBP+T96n/s9IjdkW3OLYSzcZcUuXphtqJlg=; b=vJHDS02mK9FCUOuObiEeosr+PGZPc+H2HWSvdzjj7lQicJf+6W0ik7rwy+ru9YWU8Y Bl3tEYcmnjsGQXMwulOgS5cupZH1w5TvYGAVgi1CE82BlV+u6l/nwBqgL8eLwve7Vbwh Dh5BJAJHMfsyD2duUREHhSbYCW6wBkNe532FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LblhYc4NmipTyeOYpOk6tDJO96xE7D/VEDh8p9WSqYgbbQXhciSXRhsS2d3SGDHoRE hKm2TgGmxbTwzSuGJbbInAR0cslR9ggjIxgda0dY3iutQ3YkBebsjc+3rrp36gXDMc6E NqGIQIO0MzQw4lrtb+um33yv6InYrdfq43bxY= MIME-Version: 1.0 Received: by 10.223.64.201 with SMTP id f9mr1566971fai.102.1300470220296; Fri, 18 Mar 2011 10:43:40 -0700 (PDT) Received: by 10.223.100.16 with HTTP; Fri, 18 Mar 2011 10:43:40 -0700 (PDT) In-Reply-To: <4D837C27.4040802@gmail.com> References: <4D7DFC6F.80008@gmail.com> <4D7E0831.4060804@gmail.com> <4D834F35.5030806@gmail.com> <4D837C27.4040802@gmail.com> Date: Fri, 18 Mar 2011 18:43:40 +0100 Message-ID: From: Mats Lindberg To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 6 vs 8.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:43:59 -0000 2011/3/18 Mark Tinguely > On 3/18/2011 10:11 AM, Mats Lindberg wrote: > > > > 2011/3/18 Mark Tinguely > >> On 3/18/2011 3:35 AM, Mats Lindberg wrote: >> >>> So - after a while I've made some observations. >>> My problem is actually connected to arp. >>> >>> My config is very static so basically I want to turn off arp requests. >>> Somewhere in the startup scripts I did >>> > sysctl -w net.link.ether.inet.max_age=2147483647 (max accepted value) >>> Which on freebsd-6.x worked fine. >>> In freebsd-8.1 this makes the kernel arp functionality go bezerk - >>> probably an integer overflow somewhere. >>> arp requests were sent countinously from my freebsd-8.1 node to others, >>> flooding the network. >>> I tried to lower this value and found that 500000000s works fine >>> 1000000000s does not. 500000000s is OK to me so I won't try to narrow it >>> down more. >>> >>> The reason I was suspecting swapping problems was that after a while with >>> the flooding going on I got a kernel panic saying 'page fault', which I >>> would guess is a another bug, but, with a sensible setting on the arp >>> timeout the kernel panic does not show itself any longer. >>> >>> I've googled for my arp-setting problem but not found anything on it. So >>> - maybe I'm the first to see this. >>> Should I enter a bug report somewhere? >>> I guess this forum is not the place. >>> >>> /Mats >>> >>> >> Did your HZ (timer interrupts per second) increase from 100 on FreeBSD-6 >> to 1000 on FreeBSD-8.1? This must be a 32 bit computer / OS because that >> variable is multiplied to hz: >> >> canceled = callout_reset(&la->la_timer, >> hz * V_arpt_keep, arptimer, la); >> >> and: >> >> #define callout_reset(c, on_tick, fn, arg) \ >> callout_reset_on((c), (on_tick), (fn), (arg), (c)->c_cpu) >> >> where: >> >> int callout_reset_on(struct callout *, int , void (*ftn)(void *), void *, >> int) >> >> I would guess that you are wrapping with 32 bit arithmetic to a small >> value. Both the hz==100 and hz==1000 will wrap to about the same number (a >> negative number). I did not look at the FreeBSD 6.x callout, but I think in >> the FreeBSD 8 callout, negative on_tick will be immediately called on the >> next tick.. >> > > Yes I could imagine this is it. > > >> >> A page fault panic is a kernel access to a non-mapped VA (a bad pointer). >> The panic message would have the VA and instruction address information. >> >> --Mark >> > > Well, > Both systems are i386 32bit > > On FreeBSD-6 I have: (GENERIC) kernel > kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } > On FreeBSD-8 I have:(Excluded some drivers from GENERIC kernel) > kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } > kern.hz: 1000 > > So same HZ -- seems the callout is implemented differently 6.x->8.1 > > For the kernel panic I get > fault virtual address: 0x8 > instruction pointer: 0x20:0xc0679ed7 > current process: 0, (em0 taskq) > > I don't know anything about these numbers, or if you even did want to know. > To me I get the feeling that this is connected to my arp problem, seems to > be something in the em driver that is not handled at this high load. > > I'm quite happy now - my system has been up and running for the whole day - > so I'll leave it at this - thanks > > /Mats > > Good news. > > After the reply, I did look at the FreeBSD 6.4 ARP code > (sys/netinet/if_ether.c) and the code changed between FreeBSD 6 and 8. I > would suggest that if you set the max arp number, that it be less than > (2^32-1)/hz. This value is added to the route time out value also, so be > careful on the value. > > The fault va/instruction pointer is a classic NULL pointer dereference. > > --Mark. > Good, many thanks... Just out of interest - is this a bug? 1) The sysctl accepting values it can't handle 2) The kernel/em driver panic? In my world it would be... /Mats From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 18:10:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 467D61065670; Fri, 18 Mar 2011 18:10:19 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Fri, 18 Mar 2011 14:09:58 -0400 User-Agent: KMail/1.6.2 References: <201103171436.22283.jkim@FreeBSD.org> <20110319024813.N2581@besplex.bde.org> <20110319035138.H3038@besplex.bde.org> In-Reply-To: <20110319035138.H3038@besplex.bde.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103181410.00726.jkim@FreeBSD.org> Cc: Kostik Belousov , Bruce Evans , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:10:21 -0000 On Friday 18 March 2011 01:05 pm, Bruce Evans wrote: > On Sat, 19 Mar 2011, Bruce Evans wrote: > > On Fri, 18 Mar 2011, Kostik Belousov wrote: > >> We definitely do not support configurations with different > >> models of CPUs in SMP, this is what Simmetric is about. > >> Different as in frequency or stepping. > > > > ... > > Now there is even more asymmetry > > in core frequencies, with the hardware transiently slowing down > > or stopping cores independently, at least for cores in different > > packages. > > Also, with virtualization, the virtualizer cannot reasonably even > provide an invariant TSC that runs at the same rate on all cores. > It should provide an invariant TSC that claims to run at the same > rate on all cores, but then the cores cannot run at the same rate > except on average, since some of the cores will have to run the > virtualizer some of the time, and it is unreasonable to distribute > the overhead for this evenly except on average. Ah, virtualization... It is really painful to make it reasonably correct. For example, VMware claims that all timers (including TSC and excluding RTC) runs at "apparent time", which is concept of constant ticks in virtualized guest. It also means TSCs are always "virtually" constant and synchronized across all virtual cores in guest environment. If it loses periodic timer ticks, lost ticks are "compensated" later. This also means timecounter does not exactly scale well based on realtime and its frequency fluctuates so much, if my understanding is correct: http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf I am not sure how others handle this but VirtualBox gives me really wacky TSC frequency sometimes. When it happens, it becomes unusably slow. So, I know something is really wrong there, too. However, Xen seems to do much smarter than that because it has its own concept of virtual TSC, thanks to its para-virtualization architecture. Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 20:12:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD46106564A; Fri, 18 Mar 2011 20:12:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 159228FC1A; Fri, 18 Mar 2011 20:11:59 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2IKBt9N063758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 22:11:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2IKBtfb079186; Fri, 18 Mar 2011 22:11:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2IKBtLD079185; Fri, 18 Mar 2011 22:11:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Mar 2011 22:11:55 +0200 From: Kostik Belousov To: Jung-uk Kim Message-ID: <20110318201155.GF78089@deviant.kiev.zoral.com.ua> References: <201103171436.22283.jkim@FreeBSD.org> <20110319024813.N2581@besplex.bde.org> <20110319035138.H3038@besplex.bde.org> <201103181410.00726.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dwd27Sc7ejlYAyGt" Content-Disposition: inline In-Reply-To: <201103181410.00726.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Bruce Evans , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:12:00 -0000 --dwd27Sc7ejlYAyGt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 18, 2011 at 02:09:58PM -0400, Jung-uk Kim wrote: > On Friday 18 March 2011 01:05 pm, Bruce Evans wrote: > > On Sat, 19 Mar 2011, Bruce Evans wrote: > > > On Fri, 18 Mar 2011, Kostik Belousov wrote: > > >> We definitely do not support configurations with different > > >> models of CPUs in SMP, this is what Simmetric is about. > > >> Different as in frequency or stepping. > > > > > > ... > > > Now there is even more asymmetry > > > in core frequencies, with the hardware transiently slowing down > > > or stopping cores independently, at least for cores in different > > > packages. > > > > Also, with virtualization, the virtualizer cannot reasonably even > > provide an invariant TSC that runs at the same rate on all cores.=20 > > It should provide an invariant TSC that claims to run at the same > > rate on all cores, but then the cores cannot run at the same rate > > except on average, since some of the cores will have to run the > > virtualizer some of the time, and it is unreasonable to distribute > > the overhead for this evenly except on average. >=20 > Ah, virtualization... It is really painful to make it reasonably=20 > correct. For example, VMware claims that all timers (including TSC=20 > and excluding RTC) runs at "apparent time", which is concept of=20 > constant ticks in virtualized guest. It also means TSCs are always=20 > "virtually" constant and synchronized across all virtual cores in=20 > guest environment. If it loses periodic timer ticks, lost ticks are=20 > "compensated" later. This also means timecounter does not exactly=20 > scale well based on realtime and its frequency fluctuates so much, if=20 > my understanding is correct: >=20 > http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf >=20 > I am not sure how others handle this but VirtualBox gives me really=20 > wacky TSC frequency sometimes. When it happens, it becomes unusably=20 > slow. So, I know something is really wrong there, too. However, Xen=20 > seems to do much smarter than that because it has its own concept of=20 > virtual TSC, thanks to its para-virtualization architecture. Most likely, all 'full-hardware' hypervisors have to disable rdtsc for guests, intercepting the instruction by trap and emulating it. This means that most basic assumptions about rdtsc are not held in virtualized environment, like relative cost or accuracy. Anyway, I was unable to make any reasonable use of virtualization except kernel debugging, which is more then satisfactory performed by QEMU. Ah, QEMU is not hypervisor. --dwd27Sc7ejlYAyGt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2DvIoACgkQC3+MBN1Mb4g0eACgma0HPQYwVhTJTaPc7YFiUt7A nW8AoJU7jXAdAVad9rnfnXLI3uCwf00l =PitS -----END PGP SIGNATURE----- --dwd27Sc7ejlYAyGt-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 18 20:45:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id ACB3C106566B; Fri, 18 Mar 2011 20:45:50 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Fri, 18 Mar 2011 16:45:40 -0400 User-Agent: KMail/1.6.2 References: <201103171436.22283.jkim@FreeBSD.org> <201103181410.00726.jkim@FreeBSD.org> <20110318201155.GF78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110318201155.GF78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103181645.41978.jkim@FreeBSD.org> Cc: Kostik Belousov , Bruce Evans , Maxim Dounin Subject: Re: get_cyclecount(9) deprecation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:45:51 -0000 On Friday 18 March 2011 04:11 pm, Kostik Belousov wrote: > On Fri, Mar 18, 2011 at 02:09:58PM -0400, Jung-uk Kim wrote: > > On Friday 18 March 2011 01:05 pm, Bruce Evans wrote: > > > On Sat, 19 Mar 2011, Bruce Evans wrote: > > > > On Fri, 18 Mar 2011, Kostik Belousov wrote: > > > >> We definitely do not support configurations with different > > > >> models of CPUs in SMP, this is what Simmetric is about. > > > >> Different as in frequency or stepping. > > > > > > > > ... > > > > Now there is even more asymmetry > > > > in core frequencies, with the hardware transiently slowing > > > > down or stopping cores independently, at least for cores in > > > > different packages. > > > > > > Also, with virtualization, the virtualizer cannot reasonably > > > even provide an invariant TSC that runs at the same rate on all > > > cores. It should provide an invariant TSC that claims to run at > > > the same rate on all cores, but then the cores cannot run at > > > the same rate except on average, since some of the cores will > > > have to run the virtualizer some of the time, and it is > > > unreasonable to distribute the overhead for this evenly except > > > on average. > > > > Ah, virtualization... It is really painful to make it reasonably > > correct. For example, VMware claims that all timers (including > > TSC and excluding RTC) runs at "apparent time", which is concept > > of constant ticks in virtualized guest. It also means TSCs are > > always "virtually" constant and synchronized across all virtual > > cores in guest environment. If it loses periodic timer ticks, > > lost ticks are "compensated" later. This also means timecounter > > does not exactly scale well based on realtime and its frequency > > fluctuates so much, if my understanding is correct: > > > > http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pd > >f > > > > I am not sure how others handle this but VirtualBox gives me > > really wacky TSC frequency sometimes. When it happens, it > > becomes unusably slow. So, I know something is really wrong > > there, too. However, Xen seems to do much smarter than that > > because it has its own concept of virtual TSC, thanks to its > > para-virtualization architecture. > > Most likely, all 'full-hardware' hypervisors have to disable rdtsc > for guests, intercepting the instruction by trap and emulating it. > This means that most basic assumptions about rdtsc are not held > in virtualized environment, like relative cost or accuracy. That's exactly what's happening with "hardware-assisted" virtualization. If it is pure emulation, it may run on arbitrary host CPU (not-translated x86 on x86) or completely artificial (translated) depending on emulators. Therefore, it has zero advantage over other timers. Sometimes, it may be worse. Good news is I added a tunable "machdep.disable_tsc" exactly for that reason. :-) > Anyway, I was unable to make any reasonable use of virtualization > except kernel debugging, which is more then satisfactory performed > by QEMU. Ah, QEMU is not hypervisor. Yeah, I've used QEMU for years for the same reason but its timing is awfully wrong and SMP is not exactly SMP there. :-( Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 19 00:53:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10026106564A for ; Sat, 19 Mar 2011 00:53:43 +0000 (UTC) (envelope-from dimitar9909@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C29818FC13 for ; Sat, 19 Mar 2011 00:53:42 +0000 (UTC) Received: by vws18 with SMTP id 18so4642934vws.13 for ; Fri, 18 Mar 2011 17:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ssPXXkmsvt8H02RFunwP7Dv0dTcCJPbbUBxaDN8ZTQo=; b=oOAi/oEFwZG/ZrZ4jTNNz6t97OUmvWZnmkqgkiiRJaH+eWGNEwmLqvj9awGei/071E Qv6XlTBrRgEPGuaKmlM4EYEekuf3RujLCXmvoWuJFtGUQPohT6wCAOc7D3MO7h03bgHY 6UzeJCrs6HvbvGTV/FGbd2Ax1NIOd3BPsW230= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FuOV4NhoVQUUkFOiJjWAD2KFJ6y1V+mwfIeTWbfFhZW+7QjJa1vXqk3oEvtBQ2yqG2 c0akPdPOpcEwxCuYXFd04Y+wwTA01wuiTPSpDH/8cCr1NOIh3GFRnoaPfJk4Y4Wv42KR ibHnAk6ieBe5Pe7u8PWYcqXjlJIN/fUb+noK8= MIME-Version: 1.0 Received: by 10.52.96.1 with SMTP id do1mr2390201vdb.285.1300494621128; Fri, 18 Mar 2011 17:30:21 -0700 (PDT) Received: by 10.220.169.132 with HTTP; Fri, 18 Mar 2011 17:30:21 -0700 (PDT) Date: Fri, 18 Mar 2011 20:30:21 -0400 Message-ID: From: J L To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question about Reverse Mappings in FreeBSD. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 00:53:43 -0000 I read an article about Reverse Mappings technique in memory management part. It improves a lot from Linux 2.4 to 2.6. I am wondering is FreeBSD also have this feature? Which source files should I go to find these? I want to do some study on this. Wish someone can enlighten me. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 19 17:05:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E5E5106567C for ; Sat, 19 Mar 2011 17:05:44 +0000 (UTC) (envelope-from forandom@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB6D8FC14 for ; Sat, 19 Mar 2011 17:05:43 +0000 (UTC) Received: by iyj12 with SMTP id 12so5989590iyj.13 for ; Sat, 19 Mar 2011 10:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=B+TsAriBMlm3yQ2T5hEcvW2Y6c/6bAz2tP5aD44zoyw=; b=SLArW5iqLYZskrBUbJX1W0Vv/f8flN19jDBcqWMFgq4gnT+aT9fyohjWFpuCIQ9PmZ yJ6tekVRjRcsif/tcGJHgOSjijs+AaZKCIp34US9cZhN5OiVVOv8qUAiP3GnK9+o48EJ gBuDlXwfvcAQhv7BxvM3GlUgcIxT/yh3KoPGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=yFIALMNSqcyM0xQA3dkfxNzVpCL89OpFFGTljMcvHh2XQUdZh4NMYE5QNRd8d7lQS+ IWCtkmFellSlIcMh0TmN3N3lElOkzoa1a31KhBU2x2n+gFwaCwhIKVgLkfOVvrfoy6CC kNdJYMqjJ8E1FdJ05lfT6aSrtAFANSCojR24U= MIME-Version: 1.0 Received: by 10.231.194.197 with SMTP id dz5mr2195612ibb.161.1300552599462; Sat, 19 Mar 2011 09:36:39 -0700 (PDT) Received: by 10.231.144.201 with HTTP; Sat, 19 Mar 2011 09:36:39 -0700 (PDT) Date: Sun, 20 Mar 2011 00:36:39 +0800 Message-ID: From: Xingxing Pan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: GSoC'11: DWARF2 call frame information X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 17:05:44 -0000 Hi, everyone. I'm a student interested in the project "DWARF2 call frame information" for Summer of Code 2011. I'd like to know which compiler I will work on to add DWARF2 support. This project is not tagged by "suggested". Will it be ok to choose it as the target? Thank you. Xingxing Pan From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 19 18:00:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BBFC1065672 for ; Sat, 19 Mar 2011 18:00:45 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.corbina.net (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id D152C8FC14 for ; Sat, 19 Mar 2011 18:00:44 +0000 (UTC) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.corbina.net (Postfix) with ESMTP id 40432CA5C7; Sat, 19 Mar 2011 20:41:21 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.22.99] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 309709321; Sat, 19 Mar 2011 20:41:21 +0300 Received: from dchagin.static.corbina.ru (localhost [127.0.0.1]) by dchagin.static.corbina.ru (8.14.4/8.14.4) with ESMTP id p2JHfKKu033357; Sat, 19 Mar 2011 20:41:20 +0300 (MSK) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.4/8.14.4/Submit) id p2JHfF4V033356; Sat, 19 Mar 2011 20:41:15 +0300 (MSK) (envelope-from dchagin) Date: Sat, 19 Mar 2011 20:41:15 +0300 From: Chagin Dmitry To: Xingxing Pan Message-ID: <20110319174115.GA33282@dchagin.static.corbina.ru> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC'11: DWARF2 call frame information X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 18:00:45 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 20, 2011 at 12:36:39AM +0800, Xingxing Pan wrote: > Hi, everyone. >=20 > I'm a student interested in the project "DWARF2 call frame > information" for Summer of Code 2011. > I'd like to know which compiler I will work on to add DWARF2 support. > This project is not tagged by "suggested". Will it be ok to choose it > as the target? >=20 hi Xingxing, You should carefully reread the proposed idea. Especially in the "A debug kernel is not able to show stack traces with cross exceptions anymore. This is because we do not emit any dwarf2 call frame information for any assembler code, since gdb switched to the dwarf2 format" part. And, of course, this work is very important for the community. So, IMO, it will be ok as the target :) Thank you. --=20 Have fun! chd --DocE+STaALJfprDB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk2E6roACgkQ0t2Tb3OO/O1xHwCeJRiAVhFQ543+VKtL2KlHyoEg Eo0AnixuK1bF7B4zRsw1oEwh1WnwavIg =qfL4 -----END PGP SIGNATURE----- --DocE+STaALJfprDB--