From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 00:38:27 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 732ADE2 for ; Sun, 25 Nov 2012 00:38:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E615C8FC08 for ; Sun, 25 Nov 2012 00:38:26 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so7035297lbb.13 for ; Sat, 24 Nov 2012 16:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/fDwuhRJ5NlhP1D5yT2GtmYGvES3Bdto3xJV1wHh2Z8=; b=IsMC7O0j4JFX8bKVe7Bf2qiq+CpdB06GHkzh9aCCFaWlX6lNpD9ss8oY6Kw9Mn3piN FWiS2a5IeVI7cKr8YUKGgrjl/6JKXCxuxwYZYjbfebwCQSf37/Ts7LKNKs1DU4D82rLe +eN+mxA7Wg6MPGwbxDLeENvEfB6/8ApnPiIFpEq3r1XfzOiu8MDwFDWkbeoBNBDofSVM Vp23U7uOPbllvR2Sg44j+RGznokAyJwUiabRe37XtzBw2jfBfJIGQ+Woe/lCRKALn3Kc v4XeRKUGApmdqSsSP31bP/hz5GuhCWjSP1plKZczJ9yiMPFINbyh5yrjX3kpxJ6W8tTh /yaQ== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr7253935lab.9.1353803905573; Sat, 24 Nov 2012 16:38:25 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 16:38:25 -0800 (PST) In-Reply-To: <50B145C5.8070503@mu.org> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> Date: Sun, 25 Nov 2012 00:38:25 +0000 X-Google-Sender-Auth: VxgSE5DyJ2FBCacJrWGSlM8SYEI Message-ID: Subject: Re: [RFC] sema_wait_sig From: Attilio Rao To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 00:38:27 -0000 On Sat, Nov 24, 2012 at 10:10 PM, Alfred Perlstein wrote: > I don't understand why you are the one who is so upset. Your first email to > me implied that I had 0 smp experience. > > Let me explain why this rototilling is unneeded. > > Go download a copy of linux and observe the following: > spin_lock(&mb_cache_spinlock); > spin_unlock(&mb_cache_spinlock); > spin_lock_irqsave, spin_unlock_irqrestore > up() > down(dqio_mutex) > > Those apis have been available for a decade at least. > > I'll cut to the point on this. > > If you want to change HOW the underlying freebsd SMP api works to improve > performance, then please do! > > But if you want to change the actual KPI, then please realize that Linux SMP > does darn well with a KPI for SMP that's pretty much unchanged for nearly 10 > years. > > I would venture to say in this respect we've become what we used to mock > Linux for, an OS that gratuitously changes interfaces for the sake of what > is cool, versus what our vendors need. Keeping old mechanisms/duplicate/etc. around just because they existed 10 years ago is not a good reason once their KPI is not only redundant but also dangerous. And this seems to be your only "technical" reason opposed to my proposals. Using disown for lockmgr is something very dangerous which should not be used out of his specific case for the buffer cache. I really don't want to incourage its use out of that and I'm sure people can build very dangerous policies using it (this is just an example, but it explains my point, I think). Maybe my proposed changes of mtx against rwlock are a bit too extreme, I could understand that and I'm very open on changing my mind on it, but I don't understand how would be useful to keep lockmgr() and sema() around honestly. It is just a burden of code duplication (in some places) and dangerous KPI (in other). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 01:03:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D919A476; Sun, 25 Nov 2012 01:03:54 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B2ABF8FC0C; Sun, 25 Nov 2012 01:03:54 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 45D291A3C1A; Sat, 24 Nov 2012 17:03:54 -0800 (PST) Message-ID: <50B16E7A.60900@mu.org> Date: Sat, 24 Nov 2012 17:03:54 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 01:03:55 -0000 On 11/24/12 4:38 PM, Attilio Rao wrote: > On Sat, Nov 24, 2012 at 10:10 PM, Alfred Perlstein wrote: >> I don't understand why you are the one who is so upset. Your first email to >> me implied that I had 0 smp experience. >> >> Let me explain why this rototilling is unneeded. >> >> Go download a copy of linux and observe the following: >> spin_lock(&mb_cache_spinlock); >> spin_unlock(&mb_cache_spinlock); >> spin_lock_irqsave, spin_unlock_irqrestore >> up() >> down(dqio_mutex) >> >> Those apis have been available for a decade at least. >> >> I'll cut to the point on this. >> >> If you want to change HOW the underlying freebsd SMP api works to improve >> performance, then please do! >> >> But if you want to change the actual KPI, then please realize that Linux SMP >> does darn well with a KPI for SMP that's pretty much unchanged for nearly 10 >> years. >> >> I would venture to say in this respect we've become what we used to mock >> Linux for, an OS that gratuitously changes interfaces for the sake of what >> is cool, versus what our vendors need. > Keeping old mechanisms/duplicate/etc. around just because they existed > 10 years ago is not a good reason once their KPI is not only redundant > but also dangerous. And this seems to be your only "technical" reason > opposed to my proposals. Whoa, wait a second. A user just proposed using the infrastructure to port linux drivers. Additionally the following subsystems make use of sema(9): inifiband stack (linux compat shim). sysv ipc. ata. opensolaris compat shim. xfs. What would be the point of removing this KPI? Those consumers would then just have to roll their own. Wouldn't that lead to duplicate code? 176 sys/kern/kern_sema.c It's not really a lot of code. > Using disown for lockmgr is something very dangerous which should not > be used out of his specific case for the buffer cache. I really don't > want to incourage its use out of that and I'm sure people can build > very dangerous policies using it (this is just an example, but it > explains my point, I think). > Maybe my proposed changes of mtx against rwlock are a bit too extreme, > I could understand that and I'm very open on changing my mind on it, > but I don't understand how would be useful to keep lockmgr() and > sema() around honestly. > > It is just a burden of code duplication (in some places) and dangerous > KPI (in other). I agree that lockmgr is a very dangerous beast. Whatever that can be done to get rid of the complexity would be good. If we could hide some of the lockmgr "features" behind a "I know what i'm doing fence" or maybe a "only to be used with filesystem code" fence that might be good. -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 01:16:17 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E21F4566 for ; Sun, 25 Nov 2012 01:16:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 577278FC13 for ; Sun, 25 Nov 2012 01:16:17 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so9639310lah.13 for ; Sat, 24 Nov 2012 17:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3LlfjVcIGuc19aXdqrUN1aVgQc+RE22lyB9+1b6zEH0=; b=bjYrTYoO1dnXcouHWc4Zb0IVHWc5WbC6ecT2WpMVqrjkX2TUxgie/rRH85Lbor4Xgl VFOltQj1ZB8OZdqAgOBX04MYKZvE34fUNFQJaBz9w7UcQiRHhlkV7WDU+X7z7JSyvEY6 LyUjAhqgwEl2r1uo+hCC0HoUIHnnHkv/IH196G8BInQo2HEym6qV785LZWkRHrt/8DYr yuUDyZVDo3Ye8gB6AOXdl6GN2WHZTH+5Xt9Z+35+B9gAkrNLWXAaKPtJ/8QgdN2lXp9g /Whl+x2i70vr4Qa5x0/PhYhxqecx2eaKa4gE45axCFVKCnm+jCE6uKy/q5Oyjr/iyYQv pg8w== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr7179105lab.15.1353806175256; Sat, 24 Nov 2012 17:16:15 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sat, 24 Nov 2012 17:16:15 -0800 (PST) In-Reply-To: <50B16E7A.60900@mu.org> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> Date: Sun, 25 Nov 2012 01:16:15 +0000 X-Google-Sender-Auth: bnJXC0ULBLMNLtiadV_XRypGRJo Message-ID: Subject: Re: [RFC] sema_wait_sig From: Attilio Rao To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 01:16:18 -0000 On Sun, Nov 25, 2012 at 1:03 AM, Alfred Perlstein wrote: > On 11/24/12 4:38 PM, Attilio Rao wrote: >> >> On Sat, Nov 24, 2012 at 10:10 PM, Alfred Perlstein wrote: >>> >>> I don't understand why you are the one who is so upset. Your first email >>> to >>> me implied that I had 0 smp experience. >>> >>> Let me explain why this rototilling is unneeded. >>> >>> Go download a copy of linux and observe the following: >>> spin_lock(&mb_cache_spinlock); >>> spin_unlock(&mb_cache_spinlock); >>> spin_lock_irqsave, spin_unlock_irqrestore >>> up() >>> down(dqio_mutex) >>> >>> Those apis have been available for a decade at least. >>> >>> I'll cut to the point on this. >>> >>> If you want to change HOW the underlying freebsd SMP api works to improve >>> performance, then please do! >>> >>> But if you want to change the actual KPI, then please realize that Linux >>> SMP >>> does darn well with a KPI for SMP that's pretty much unchanged for nearly >>> 10 >>> years. >>> >>> I would venture to say in this respect we've become what we used to mock >>> Linux for, an OS that gratuitously changes interfaces for the sake of >>> what >>> is cool, versus what our vendors need. >> >> Keeping old mechanisms/duplicate/etc. around just because they existed >> 10 years ago is not a good reason once their KPI is not only redundant >> but also dangerous. And this seems to be your only "technical" reason >> opposed to my proposals. > > Whoa, wait a second. > > A user just proposed using the infrastructure to port linux drivers. > > Additionally the following subsystems make use of sema(9): > inifiband stack (linux compat shim). > sysv ipc. > ata. > opensolaris compat shim. > xfs. > > What would be the point of removing this KPI? Did you see also how they are used? In some places they have a counter of 1, which means they can be effectively replaced by an sx lock. In all the other places, they are used with a counter of 0, which means they can be effectively replaced by mtx and sleep. Can you giving me a reason on why really keeping them? Also, if you think they would help a Linux compat shim layer, keep in mind the following: - a plan for something like that has been discussed for years and by several people and nothing concrete, happened, with a lot of disagreement (both technical and philosophical) - there is no plan for doing so in the foreeable future, neither there is agreement it is really a good idea. So you prefer to have completely redundant (and unused in the end) code just because it may or may not happen to help a compat layer that doesn't exist and maybe will never exits? Please answer openly. > > Those consumers would then just have to roll their own. > > Wouldn't that lead to duplicate code? > > 176 sys/kern/kern_sema.c > > It's not really a lot of code. > > >> Using disown for lockmgr is something very dangerous which should not >> be used out of his specific case for the buffer cache. I really don't >> want to incourage its use out of that and I'm sure people can build >> very dangerous policies using it (this is just an example, but it >> explains my point, I think). >> Maybe my proposed changes of mtx against rwlock are a bit too extreme, >> I could understand that and I'm very open on changing my mind on it, >> but I don't understand how would be useful to keep lockmgr() and >> sema() around honestly. >> >> It is just a burden of code duplication (in some places) and dangerous >> KPI (in other). > > I agree that lockmgr is a very dangerous beast. Whatever that can be done > to get rid of the complexity would be good. > > If we could hide some of the lockmgr "features" behind a "I know what i'm > doing fence" or maybe a "only to be used with filesystem code" fence that > might be good. I don't agree, I would just like to have a clean KPI and force people to do right things. That clean KPI already exists, we just need to conver current consumers in doing their dirtiness in "controled environment". Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 01:47:16 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C4C7887; Sun, 25 Nov 2012 01:47:16 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1692D8FC0C; Sun, 25 Nov 2012 01:47:15 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 6820A1A3C4B; Sat, 24 Nov 2012 17:47:15 -0800 (PST) Message-ID: <50B178A3.4070305@mu.org> Date: Sat, 24 Nov 2012 17:47:15 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 01:47:16 -0000 On 11/24/12 5:16 PM, Attilio Rao wrote: > On Sun, Nov 25, 2012 at 1:03 AM, Alfred Perlstein wrote: >> On 11/24/12 4:38 PM, Attilio Rao wrote: >>> On Sat, Nov 24, 2012 at 10:10 PM, Alfred Perlstein wrote: >>>> I don't understand why you are the one who is so upset. Your first email >>>> to >>>> me implied that I had 0 smp experience. >>>> >>>> Let me explain why this rototilling is unneeded. >>>> >>>> Go download a copy of linux and observe the following: >>>> spin_lock(&mb_cache_spinlock); >>>> spin_unlock(&mb_cache_spinlock); >>>> spin_lock_irqsave, spin_unlock_irqrestore >>>> up() >>>> down(dqio_mutex) >>>> >>>> Those apis have been available for a decade at least. >>>> >>>> I'll cut to the point on this. >>>> >>>> If you want to change HOW the underlying freebsd SMP api works to improve >>>> performance, then please do! >>>> >>>> But if you want to change the actual KPI, then please realize that Linux >>>> SMP >>>> does darn well with a KPI for SMP that's pretty much unchanged for nearly >>>> 10 >>>> years. >>>> >>>> I would venture to say in this respect we've become what we used to mock >>>> Linux for, an OS that gratuitously changes interfaces for the sake of >>>> what >>>> is cool, versus what our vendors need. >>> Keeping old mechanisms/duplicate/etc. around just because they existed >>> 10 years ago is not a good reason once their KPI is not only redundant >>> but also dangerous. And this seems to be your only "technical" reason >>> opposed to my proposals. >> Whoa, wait a second. >> >> A user just proposed using the infrastructure to port linux drivers. >> >> Additionally the following subsystems make use of sema(9): >> inifiband stack (linux compat shim). >> sysv ipc. >> ata. >> opensolaris compat shim. >> xfs. >> >> What would be the point of removing this KPI? > Did you see also how they are used? > In some places they have a counter of 1, which means they can be > effectively replaced by an sx lock. > In all the other places, they are used with a counter of 0, which > means they can be effectively replaced by mtx and sleep. > > Can you giving me a reason on why really keeping them? > > Also, if you think they would help a Linux compat shim layer, keep in > mind the following: > - a plan for something like that has been discussed for years and by > several people and nothing concrete, happened, with a lot of > disagreement (both technical and philosophical) > - there is no plan for doing so in the foreeable future, neither there > is agreement it is really a good idea. So you prefer to have > completely redundant (and unused in the end) code just because it may > or may not happen to help a compat layer that doesn't exist and maybe > will never exits? Please answer openly. 1) compat layer /usr/src.local/sys/ofed/drivers/infiniband/core # cddl/contrib/opensolaris 2) if a user expects semaphores and we tell them to "rethink" things, then we're not providing the same facilities as every other non-BSD OS. I guess that makes us "cool", but really it just seems out of touch. The implementation is 176 lines of code + some headers. The sad part to me is that the original user asked "hey I need sema+signal" but we don't know the facility they really need, count of 1? count of 10? instead of just giving them a textbook CS semaphore we tell them to "build your own using our primitives". At some point an OS has to grow up and realize that by doing everything its own way it's not making itself special, so much as limiting its acceptance. >> Those consumers would then just have to roll their own. >> >> Wouldn't that lead to duplicate code? >> >> 176 sys/kern/kern_sema.c >> >> It's not really a lot of code. >> >> >>> Using disown for lockmgr is something very dangerous which should not >>> be used out of his specific case for the buffer cache. I really don't >>> want to incourage its use out of that and I'm sure people can build >>> very dangerous policies using it (this is just an example, but it >>> explains my point, I think). >>> Maybe my proposed changes of mtx against rwlock are a bit too extreme, >>> I could understand that and I'm very open on changing my mind on it, >>> but I don't understand how would be useful to keep lockmgr() and >>> sema() around honestly. >>> >>> It is just a burden of code duplication (in some places) and dangerous >>> KPI (in other). >> I agree that lockmgr is a very dangerous beast. Whatever that can be done >> to get rid of the complexity would be good. >> >> If we could hide some of the lockmgr "features" behind a "I know what i'm >> doing fence" or maybe a "only to be used with filesystem code" fence that >> might be good. > I don't agree, I would just like to have a clean KPI and force people > to do right things. That clean KPI already exists, we just need to > conver current consumers in doing their dirtiness in "controled > environment". Well I was just trying to agree with you, to be honest I have no idea what your plans are. I did want to explain that merging sx+lockmgr was tried before, and it failed. You may have more skill with it and succeed, but you should check source history and mailing lists for the edge cases that made replacing it entirely fail. -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 01:56:28 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FE52970 for ; Sun, 25 Nov 2012 01:56:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 119808FC0C for ; Sun, 25 Nov 2012 01:56:27 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so10569105iec.13 for ; Sat, 24 Nov 2012 17:56:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5kFNywY75l5VOpgLoQQI+yPVuoy8q/kutkJaLtBzlrg=; b=UK8EEwtNnf6lGaRy8lqOCwg42g6Y3ZPo1T+bU66d9JHJ8zEcdnCcBEUN/kJP9QEduy +UrbI/+zJvDQ1YRUmPQUC/acqyFgA92gME1kzI4h8xcnlGVTxW3IAkZtlSJE5A+xoF+l ClzcONz6ddJCixN6+m0EQznTg8rEzo+UbiJxUtYWN4zhf+KUA85UyahqhLXTAEuwmlW7 +7lPX05swxi9ZJpxM9caHvqTb4WKjO7tL+jVY2plSO/wuZCSVTbdGsXbFqxe1Ru2k39a aLfhhO05HuQD0HOQwED233glQGCXQKBmWcmHmT04CaQHwBO/u3SDAZknPMFq9YZK24xM ZPBw== Received: by 10.43.105.129 with SMTP id dq1mr6691717icc.31.1353808586663; Sat, 24 Nov 2012 17:56:26 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fa6sm8449191igb.2.2012.11.24.17.56.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Nov 2012 17:56:24 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] sema_wait_sig Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50B178A3.4070305@mu.org> Date: Sat, 24 Nov 2012 18:56:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> <50B178A3.4070305@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnGwGsYvFtm+YrzHVemWmvjwXqk/rHl0yxsvAZOB/ENfJ5Bvkhf9BQETMwtWcDTrNDOTge7 Cc: attilio@FreeBSD.org, Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 01:56:28 -0000 On Nov 24, 2012, at 6:47 PM, Alfred Perlstein wrote: > On 11/24/12 5:16 PM, Attilio Rao wrote: >> On Sun, Nov 25, 2012 at 1:03 AM, Alfred Perlstein = wrote: >>> On 11/24/12 4:38 PM, Attilio Rao wrote: >>>> On Sat, Nov 24, 2012 at 10:10 PM, Alfred Perlstein = wrote: >>>>> I don't understand why you are the one who is so upset. Your = first email >>>>> to >>>>> me implied that I had 0 smp experience. >>>>>=20 >>>>> Let me explain why this rototilling is unneeded. >>>>>=20 >>>>> Go download a copy of linux and observe the following: >>>>> spin_lock(&mb_cache_spinlock); >>>>> spin_unlock(&mb_cache_spinlock); >>>>> spin_lock_irqsave, spin_unlock_irqrestore >>>>> up() >>>>> down(dqio_mutex) >>>>>=20 >>>>> Those apis have been available for a decade at least. >>>>>=20 >>>>> I'll cut to the point on this. >>>>>=20 >>>>> If you want to change HOW the underlying freebsd SMP api works to = improve >>>>> performance, then please do! >>>>>=20 >>>>> But if you want to change the actual KPI, then please realize that = Linux >>>>> SMP >>>>> does darn well with a KPI for SMP that's pretty much unchanged for = nearly >>>>> 10 >>>>> years. >>>>>=20 >>>>> I would venture to say in this respect we've become what we used = to mock >>>>> Linux for, an OS that gratuitously changes interfaces for the sake = of >>>>> what >>>>> is cool, versus what our vendors need. >>>> Keeping old mechanisms/duplicate/etc. around just because they = existed >>>> 10 years ago is not a good reason once their KPI is not only = redundant >>>> but also dangerous. And this seems to be your only "technical" = reason >>>> opposed to my proposals. >>> Whoa, wait a second. >>>=20 >>> A user just proposed using the infrastructure to port linux drivers. >>>=20 >>> Additionally the following subsystems make use of sema(9): >>> inifiband stack (linux compat shim). >>> sysv ipc. >>> ata. >>> opensolaris compat shim. >>> xfs. >>>=20 >>> What would be the point of removing this KPI? >> Did you see also how they are used? >> In some places they have a counter of 1, which means they can be >> effectively replaced by an sx lock. >> In all the other places, they are used with a counter of 0, which >> means they can be effectively replaced by mtx and sleep. >>=20 >> Can you giving me a reason on why really keeping them? >>=20 >> Also, if you think they would help a Linux compat shim layer, keep in >> mind the following: >> - a plan for something like that has been discussed for years and by >> several people and nothing concrete, happened, with a lot of >> disagreement (both technical and philosophical) >> - there is no plan for doing so in the foreeable future, neither = there >> is agreement it is really a good idea. So you prefer to have >> completely redundant (and unused in the end) code just because it may >> or may not happen to help a compat layer that doesn't exist and maybe >> will never exits? Please answer openly. >=20 > 1) compat layer > /usr/src.local/sys/ofed/drivers/infiniband/core # > cddl/contrib/opensolaris >=20 > 2) > if a user expects semaphores and we tell them to "rethink" things, = then we're not providing the same facilities as every other non-BSD OS. >=20 > I guess that makes us "cool", but really it just seems out of touch. >=20 > The implementation is 176 lines of code + some headers. >=20 > The sad part to me is that the original user asked "hey I need = sema+signal" but we don't know the facility they really need, count of = 1? count of 10? instead of just giving them a textbook CS semaphore we = tell them to "build your own using our primitives". You don't need stdio, you can build it from the syscall primitives... Warner > At some point an OS has to grow up and realize that by doing = everything its own way it's not making itself special, so much as = limiting its acceptance. >=20 >>> Those consumers would then just have to roll their own. >>>=20 >>> Wouldn't that lead to duplicate code? >>>=20 >>> 176 sys/kern/kern_sema.c >>>=20 >>> It's not really a lot of code. >>>=20 >>>=20 >>>> Using disown for lockmgr is something very dangerous which should = not >>>> be used out of his specific case for the buffer cache. I really = don't >>>> want to incourage its use out of that and I'm sure people can build >>>> very dangerous policies using it (this is just an example, but it >>>> explains my point, I think). >>>> Maybe my proposed changes of mtx against rwlock are a bit too = extreme, >>>> I could understand that and I'm very open on changing my mind on = it, >>>> but I don't understand how would be useful to keep lockmgr() and >>>> sema() around honestly. >>>>=20 >>>> It is just a burden of code duplication (in some places) and = dangerous >>>> KPI (in other). >>> I agree that lockmgr is a very dangerous beast. Whatever that can = be done >>> to get rid of the complexity would be good. >>>=20 >>> If we could hide some of the lockmgr "features" behind a "I know = what i'm >>> doing fence" or maybe a "only to be used with filesystem code" fence = that >>> might be good. >> I don't agree, I would just like to have a clean KPI and force people >> to do right things. That clean KPI already exists, we just need to >> conver current consumers in doing their dirtiness in "controled >> environment". >=20 > Well I was just trying to agree with you, to be honest I have no idea = what your plans are. >=20 > I did want to explain that merging sx+lockmgr was tried before, and it = failed. You may have more skill with it and succeed, but you should = check source history and mailing lists for the edge cases that made = replacing it entirely fail. >=20 >=20 > -Alfred > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 02:01:29 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DD9FA1E; Sun, 25 Nov 2012 02:01:29 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D736F8FC0C; Sun, 25 Nov 2012 02:01:28 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 8D2161A3C1A; Sat, 24 Nov 2012 18:01:27 -0800 (PST) Message-ID: <50B17BF7.7020609@mu.org> Date: Sat, 24 Nov 2012 18:01:27 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Warner Losh Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> <50B178A3.4070305@mu.org> <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> In-Reply-To: <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Mark Linimon , Oleksandr Tymoshenko , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 02:01:29 -0000 On 11/24/12 5:56 PM, Warner Losh wrote: > On Nov 24, 2012, at 6:47 PM, Alfred Perlstein wrote: > >> >> 1) compat layer >> /usr/src.local/sys/ofed/drivers/infiniband/core # >> cddl/contrib/opensolaris >> >> 2) >> if a user expects semaphores and we tell them to "rethink" things, then we're not providing the same facilities as every other non-BSD OS. >> >> I guess that makes us "cool", but really it just seems out of touch. >> >> The implementation is 176 lines of code + some headers. >> >> The sad part to me is that the original user asked "hey I need sema+signal" but we don't know the facility they really need, count of 1? count of 10? instead of just giving them a textbook CS semaphore we tell them to "build your own using our primitives". > You don't need stdio, you can build it from the syscall primitives... Dude, don't make me replace string.h/strncpy/strlcpy with sbuf_(9), cause I will! -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 02:22:55 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3934BC4C; Sun, 25 Nov 2012 02:22:55 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C88BE8FC0C; Sun, 25 Nov 2012 02:22:54 +0000 (UTC) Received: from [10.0.0.56] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id qAP2Mn7n054240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 24 Nov 2012 21:22:49 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Sat, 24 Nov 2012 21:22:49 -0500 (EST) References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> <50B178A3.4070305@mu.org> <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> <50B17BF7.7020609@mu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <50B17BF7.7020609@mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A525) From: Daniel Eischen Subject: Re: [RFC] sema_wait_sig Date: Sat, 24 Nov 2012 21:22:52 -0500 To: Alfred Perlstein Cc: "attilio@freebsd.org" , Mark Linimon , Oleksandr Tymoshenko , "arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 02:22:55 -0000 On Nov 24, 2012, at 9:01 PM, Alfred Perlstein wrote: > On 11/24/12 5:56 PM, Warner Losh wrote: >> On Nov 24, 2012, at 6:47 PM, Alfred Perlstein wrote: >>=20 >>>=20 >>> 1) compat layer >>> /usr/src.local/sys/ofed/drivers/infiniband/core # >>> cddl/contrib/opensolaris >>>=20 >>> 2) >>> if a user expects semaphores and we tell them to "rethink" things, then w= e're not providing the same facilities as every other non-BSD OS. >>>=20 >>> I guess that makes us "cool", but really it just seems out of touch. >>>=20 >>> The implementation is 176 lines of code + some headers. >>>=20 >>> The sad part to me is that the original user asked "hey I need sema+sign= al" but we don't know the facility they really need, count of 1? count of 1= 0? instead of just giving them a textbook CS semaphore we tell them to "buil= d your own using our primitives". >> You don't need stdio, you can build it from the syscall primitives... >=20 > Dude, don't make me replace string.h/strncpy/strlcpy with sbuf_(9), cause I= will! Can we please chill? We're not talking about getting rid of a commonly used= API with sema(9). We want to do what is right for FreeBSD, not Linux. Tha= t's not to say we can't have a Linux kernel compat shim or something, but th= ey should be hidden accordingly and not used by native drivers and such. We= definitely don't want every API for every OS, or we will become an amalgama= tion of those OSs. -- DE= From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 02:52:35 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F7C8DE2; Sun, 25 Nov 2012 02:52:35 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DEC4B8FC12; Sun, 25 Nov 2012 02:52:34 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 5EBF01A3C1A; Sat, 24 Nov 2012 18:52:34 -0800 (PST) Message-ID: <50B187F2.2040506@mu.org> Date: Sat, 24 Nov 2012 18:52:34 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> <50B178A3.4070305@mu.org> <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> <50B17BF7.7020609@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "attilio@freebsd.org" , Mark Linimon , Oleksandr Tymoshenko , "arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 02:52:35 -0000 On 11/24/12 6:22 PM, Daniel Eischen wrote: > On Nov 24, 2012, at 9:01 PM, Alfred Perlstein wrote: > >> On 11/24/12 5:56 PM, Warner Losh wrote: >>> On Nov 24, 2012, at 6:47 PM, Alfred Perlstein wrote: >>> >>>> 1) compat layer >>>> /usr/src.local/sys/ofed/drivers/infiniband/core # >>>> cddl/contrib/opensolaris >>>> >>>> 2) >>>> if a user expects semaphores and we tell them to "rethink" things, then we're not providing the same facilities as every other non-BSD OS. >>>> >>>> I guess that makes us "cool", but really it just seems out of touch. >>>> >>>> The implementation is 176 lines of code + some headers. >>>> >>>> The sad part to me is that the original user asked "hey I need sema+signal" but we don't know the facility they really need, count of 1? count of 10? instead of just giving them a textbook CS semaphore we tell them to "build your own using our primitives". >>> You don't need stdio, you can build it from the syscall primitives... >> Dude, don't make me replace string.h/strncpy/strlcpy with sbuf_(9), cause I will! > Can we please chill? We're not talking about getting rid of a commonly used API with sema(9). We want to do what is right for FreeBSD, not Linux. That's not to say we can't have a Linux kernel compat shim or something, but they should be hidden accordingly and not used by native drivers and such. We definitely don't want every API for every OS, or we will become an amalgamation of those OSs. Daniel, this is something that I really don't understand, a driver is a driver, it's a means for putting packets on the wire or bytes on disk. Sometimes the stack becomes complicated due to topologies or interesting features (hot plug), but in essence they are very much the same. I do not see the point of "FreeBSD'ing" a driver when we could share code with another OS (infiniband?). It's just duplicate effort and makes it harder to maintain. Sema is already used inside the sysv_ipc code. I don't understand the point of trying to be different for the sake of differentness. It's really not done us any favors. Our strength has been when we've surpassed the other OSes out there with innovation: examples: cam, geom, kqueue, sendfile, accept filters, audit, witness, vfs_debug, zfs. Our strength is not our different names for the same things. I would certainly be accepting of a driver in FreeBSD that used sema(9) and I think we should all, afterall our infiniband stack seems to, and that's kinda cool. -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 12:38:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3272E3B; Sun, 25 Nov 2012 12:38:10 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB6F8FC19; Sun, 25 Nov 2012 12:38:09 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 19DBAC33; Sun, 25 Nov 2012 13:36:21 +0100 (CET) Date: Sun, 25 Nov 2012 13:39:21 +0100 From: Pawel Jakub Dawidek To: Attilio Rao Subject: Re: [RFQ] make witness panic an option Message-ID: <20121125123920.GI1460@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EdRE1UL8d3mMOE6m" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 12:38:10 -0000 --EdRE1UL8d3mMOE6m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2012 at 04:39:55PM +0000, Attilio Rao wrote: > On 11/15/12, Adrian Chadd wrote: > > On 15 November 2012 05:27, Giovanni Trematerra > > wrote: > > > >> I really do think that is a very bad idea. > >> When a locking assertion fails you have just to stop your mind and > >> think what's wrong, > >> no way to postpone on this. > > > > Not all witness panics are actually fatal. For a developer who is > > sufficiently cluey in their area, they are quite likely able to just > > stare at the code paths for a while to figure out why the > > incorrectness occured. >=20 > The problem is that such mechanism can be abused, just like the > BLESSING one and that's why this is disabled by default. WITNESS is a development tool. We don't ship production kernels with WITNESS even compiled in. What is more efficient use of developer time: going through full reboot cycle every time or reading the warning from console, unloading a module, fixing the bug and loading it again? And if this option is turned off by default what is the problem? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --EdRE1UL8d3mMOE6m Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCyEXgACgkQForvXbEpPzRdpwCbBmzAAu4KdDaHCcDdEr/xq5SE HDwAoMpyO7TPU8jPupmwrg1EgSJXLljn =gpTY -----END PGP SIGNATURE----- --EdRE1UL8d3mMOE6m-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 12:42:19 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78F30180; Sun, 25 Nov 2012 12:42:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5BEBF8FC0C; Sun, 25 Nov 2012 12:42:17 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so7225582lbb.13 for ; Sun, 25 Nov 2012 04:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/ZgxWTcmy7bW4zmJmA9hpWjmPo8HwffJiEFY4Zl3HMw=; b=dWCkF44fYD/BMhGodD7WygNvt0/CKcOSuZipXG8UTj6sZmAyX9m3GdpvTbw9fop/wZ lkaSUUOE0O5gLbm4QLv5URLMAgFSfIlJPfXf4Vog0oT4v4OrmFbNSRgydG0iZmK6SwQG WtoPu7gcI4gW+0/z+AaQNgjj+Ix0iFzumN3Xyu6IdNJQ0cFaSG6B9OLeltYLuw1DSyoN AH0DlxZny3WuCU59W/xI5Ml7hUD76hOdp7aGpvAV68scK6yuCNaPFMg6PhAtFn++Qa5f phXfLa7Czu6QxuT1Jud6SUe8vs0CejWKI8hj+jXyK8owH9tByfVGjwpQ1OtNtWApYX+4 uEVA== MIME-Version: 1.0 Received: by 10.112.28.98 with SMTP id a2mr3800413lbh.110.1353847337007; Sun, 25 Nov 2012 04:42:17 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sun, 25 Nov 2012 04:42:16 -0800 (PST) In-Reply-To: <20121125123920.GI1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> Date: Sun, 25 Nov 2012 12:42:16 +0000 X-Google-Sender-Auth: A_uJPsdkWDmbZj44H85r7_DJHmg Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 12:42:19 -0000 On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek wrote: > On Thu, Nov 15, 2012 at 04:39:55PM +0000, Attilio Rao wrote: >> On 11/15/12, Adrian Chadd wrote: >> > On 15 November 2012 05:27, Giovanni Trematerra >> > wrote: >> > >> >> I really do think that is a very bad idea. >> >> When a locking assertion fails you have just to stop your mind and >> >> think what's wrong, >> >> no way to postpone on this. >> > >> > Not all witness panics are actually fatal. For a developer who is >> > sufficiently cluey in their area, they are quite likely able to just >> > stare at the code paths for a while to figure out why the >> > incorrectness occured. >> >> The problem is that such mechanism can be abused, just like the >> BLESSING one and that's why this is disabled by default. > > WITNESS is a development tool. We don't ship production kernels with > WITNESS even compiled in. What is more efficient use of developer time: > going through full reboot cycle every time or reading the warning from > console, unloading a module, fixing the bug and loading it again? > > And if this option is turned off by default what is the problem? Yes, so, why do you write here? Go ahead and fix BLESSED, make it the default, etc. I have enough of your (not referred to you particulary but to the people which contributed to this and other thread) to not be able to respect others opinion. As I said I cannot forbid you guys from doing anything, just go ahead, write the code and commit it, albeit completely bypassing other people's opinion. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 13:11:41 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8AA6916; Sun, 25 Nov 2012 13:11:41 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 758F08FC08; Sun, 25 Nov 2012 13:11:40 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 85F8CC48; Sun, 25 Nov 2012 14:09:52 +0100 (CET) Date: Sun, 25 Nov 2012 14:12:52 +0100 From: Pawel Jakub Dawidek To: Attilio Rao Subject: Re: [RFQ] make witness panic an option Message-ID: <20121125131252.GJ1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/0U0QBNx7JIUZLHm" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 13:11:42 -0000 --/0U0QBNx7JIUZLHm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 25, 2012 at 12:42:16PM +0000, Attilio Rao wrote: > On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek w= rote: > > WITNESS is a development tool. We don't ship production kernels with > > WITNESS even compiled in. What is more efficient use of developer time: > > going through full reboot cycle every time or reading the warning from > > console, unloading a module, fixing the bug and loading it again? > > > > And if this option is turned off by default what is the problem? >=20 > Yes, so, why do you write here? I'm trying to understand why do you object. Until now the only concern you have that I found is that you are afraid of it being abused. I don't see how this can be abused if it is turned off by default. If someone will commit a change that will turn it on by default, believe me, I'll unleash hell personally. As I said, WITNESS is development tool, a very handy one. This doesn't mean we can't make it even more handy. It is there to help find bugs faster, right? Adrian is proposing a change that will make it help to find and fix bugs maybe even faster. > Go ahead and fix BLESSED, make it the default, etc. This is another story, but BLESSED is much less controversial to me. It is turned off by default in assumption that all the code that runs in our kernel is developed for FreeBSD, which is not true. For example ZFS is, I think, the biggest locking consumer in our kernel (around 120 locks), which wasn't originally developed for FreeBSD and locking order was verified using different tools. Now on FreeBSD it triggers massive LOR warnings from WITNESS, eventhough those are not bugs. At some point I verified many of them and they were all false-positives, so I simply turned off WITNESS warnings for ZFS locks. Why? Because BLESSED is turned off in fear of abuse, and this is turn is the cause of mentioned hack in ZFS. > I have enough of your (not referred to you particulary but to the > people which contributed to this and other thread) to not be able to > respect others opinion. > As I said I cannot forbid you guys from doing anything, just go ahead, > write the code and commit it, albeit completely bypassing other > people's opinion. I'm sorry, I wasn't aware that your opinions are set in stone. I hoped that with some new arguments you may want to reconsider:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --/0U0QBNx7JIUZLHm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCyGVQACgkQForvXbEpPzTD7wCghovfDQb54c7N9qdn+GkhKYZH 4PkAoOK2W1rVxX032BdbCFvgrE1u8Zwv =tTdM -----END PGP SIGNATURE----- --/0U0QBNx7JIUZLHm-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 13:37:22 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30972506; Sun, 25 Nov 2012 13:37:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7448FC17; Sun, 25 Nov 2012 13:37:20 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so7247376lbb.13 for ; Sun, 25 Nov 2012 05:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sOy3O2jzaHqSDtvrM8xlzBIK1ymFObmKgtpUb9/hY+M=; b=sHChh4l4gqmqbjKEBXM5LtzNGYoIAa4r5h6Ii0+kbZJnHy+EwWRnXZETcnADaZh25R DCsxoPMvTfTkkfcySMiExWXx4FvOCwzZcyjrcCXQlZRfanc5/p8a7QsSPSgwuLJBV8W2 h1W/b7HYPWmdl3ew4XexZcOfSC5mhanS8EUJ/3hqPtTyABXO+LakdtiONeN3WnDKT/FV OCXbudjlYcoFWixMBrtJdUrA9LNWcw4oIyTZzsP/hCRw6zukliEzHkkpkraH6QLhulG5 2KVGEhtWI/l3v5oTffrchiI2oMKOYOPbfU1K7Ohy7ZEh42Ru10sThHf5q8BAyisxfVwN ndoA== MIME-Version: 1.0 Received: by 10.112.26.67 with SMTP id j3mr3979866lbg.39.1353850639777; Sun, 25 Nov 2012 05:37:19 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sun, 25 Nov 2012 05:37:19 -0800 (PST) In-Reply-To: <20121125131252.GJ1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> <20121125131252.GJ1460@garage.freebsd.pl> Date: Sun, 25 Nov 2012 13:37:19 +0000 X-Google-Sender-Auth: N8EJXNjtOLmV3R7ZWDhW0Zp7oV0 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 13:37:22 -0000 On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek wrote: > On Sun, Nov 25, 2012 at 12:42:16PM +0000, Attilio Rao wrote: >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek wrote: >> > WITNESS is a development tool. We don't ship production kernels with >> > WITNESS even compiled in. What is more efficient use of developer time: >> > going through full reboot cycle every time or reading the warning from >> > console, unloading a module, fixing the bug and loading it again? >> > >> > And if this option is turned off by default what is the problem? >> >> Yes, so, why do you write here? > > I'm trying to understand why do you object. Until now the only concern > you have that I found is that you are afraid of it being abused. I don't > see how this can be abused if it is turned off by default. If someone > will commit a change that will turn it on by default, believe me, I'll > unleash hell personally. So I don't understand what are you proposing. You are not proposing to switch BLESSING on and you are not proposing to import Adrian's patches in, if I get it correctly. I don't understand then. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 13:46:33 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5B4D795; Sun, 25 Nov 2012 13:46:33 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBF98FC12; Sun, 25 Nov 2012 13:46:32 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id C074EC5C; Sun, 25 Nov 2012 14:44:43 +0100 (CET) Date: Sun, 25 Nov 2012 14:47:43 +0100 From: Pawel Jakub Dawidek To: Attilio Rao Subject: Re: [RFQ] make witness panic an option Message-ID: <20121125134743.GK1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> <20121125131252.GJ1460@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OOq1TgGhe8eTwFBO" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 13:46:33 -0000 --OOq1TgGhe8eTwFBO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 25, 2012 at 01:37:19PM +0000, Attilio Rao wrote: > On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek wr= ote: > > On Sun, Nov 25, 2012 at 12:42:16PM +0000, Attilio Rao wrote: > >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek wrote: > >> > WITNESS is a development tool. We don't ship production kernels with > >> > WITNESS even compiled in. What is more efficient use of developer ti= me: > >> > going through full reboot cycle every time or reading the warning fr= om > >> > console, unloading a module, fixing the bug and loading it again? > >> > > >> > And if this option is turned off by default what is the problem? > >> > >> Yes, so, why do you write here? > > > > I'm trying to understand why do you object. Until now the only concern > > you have that I found is that you are afraid of it being abused. I don't > > see how this can be abused if it is turned off by default. If someone > > will commit a change that will turn it on by default, believe me, I'll > > unleash hell personally. >=20 > So I don't understand what are you proposing. > You are not proposing to switch BLESSING on and you are not proposing > to import Adrian's patches in, if I get it correctly. I don't > understand then. I propose to get Adrian's patches in, just leave current behaviour as the default. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --OOq1TgGhe8eTwFBO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCyIX8ACgkQForvXbEpPzQlJQCeIlqNSY/OZwVQHNSHjq1nQxsl c50AoJRjD25nFJxD+fAuVT4q0EJZXVBQ =ReUf -----END PGP SIGNATURE----- --OOq1TgGhe8eTwFBO-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 13:48:26 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0330F92F; Sun, 25 Nov 2012 13:48:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C3D448FC08; Sun, 25 Nov 2012 13:48:24 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so9846135lah.13 for ; Sun, 25 Nov 2012 05:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pYYhZu8E2pPTj413sT1sGPEGOm84VyS5rufs5O1XPn8=; b=UX7kXfFTT4sFMjqUZX8qjMW8NW1MalkBhuHdL87B5ViDJ1VXAG1oQc/XwHcy/RYZKj c1JhJEY/n0kGEPbYQZTmDvdcFSXOVSNBKus3m99/1iwoO6V78mqC0fYDQWVbTgtD9DXT XyrQ1Ni4x2MNoa/Vok7LgeMeDhefZkbCCz6pLQ5Re09qoMgc6KZDqh73vpSSaPtPKNo6 q6FDl2jKmLC8crxwttXDAb70YZN0npOFNldijBrlGxpmNqyQsXHnB0KNju3ipH4ROyt8 AautPe6bmxbxxdvjmNGERyzyECa0t9sknmrF9SOm/o8nFywwuI+BK/cgsARfQX7Dyx3w sstg== MIME-Version: 1.0 Received: by 10.112.87.40 with SMTP id u8mr3892069lbz.50.1353851303661; Sun, 25 Nov 2012 05:48:23 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sun, 25 Nov 2012 05:48:23 -0800 (PST) In-Reply-To: <20121125134743.GK1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> <20121125131252.GJ1460@garage.freebsd.pl> <20121125134743.GK1460@garage.freebsd.pl> Date: Sun, 25 Nov 2012 13:48:23 +0000 X-Google-Sender-Auth: uMTFE7q4eFLBVQYRQO5gz28i9oo Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 13:48:26 -0000 On Sun, Nov 25, 2012 at 1:47 PM, Pawel Jakub Dawidek wrote: > On Sun, Nov 25, 2012 at 01:37:19PM +0000, Attilio Rao wrote: >> On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek wrote: >> > On Sun, Nov 25, 2012 at 12:42:16PM +0000, Attilio Rao wrote: >> >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek wrote: >> >> > WITNESS is a development tool. We don't ship production kernels with >> >> > WITNESS even compiled in. What is more efficient use of developer time: >> >> > going through full reboot cycle every time or reading the warning from >> >> > console, unloading a module, fixing the bug and loading it again? >> >> > >> >> > And if this option is turned off by default what is the problem? >> >> >> >> Yes, so, why do you write here? >> > >> > I'm trying to understand why do you object. Until now the only concern >> > you have that I found is that you are afraid of it being abused. I don't >> > see how this can be abused if it is turned off by default. If someone >> > will commit a change that will turn it on by default, believe me, I'll >> > unleash hell personally. >> >> So I don't understand what are you proposing. >> You are not proposing to switch BLESSING on and you are not proposing >> to import Adrian's patches in, if I get it correctly. I don't >> understand then. > > I propose to get Adrian's patches in, just leave current behaviour as > the default. So if I tell that I'm afraid this mechanism will be abused (and believe me, I really wanted to trimm out BLESSING stuff also for the same reason) and you say "you can't see how" there is not much we can discuss. You know how I think, there is no need to wait for me to reconsider, because I don't believe this will happen with arguments like "I don't think", "I don't agree", etc. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 14:05:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0E85138; Sun, 25 Nov 2012 14:05:09 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDC88FC08; Sun, 25 Nov 2012 14:05:09 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 1AEC3C67; Sun, 25 Nov 2012 15:03:21 +0100 (CET) Date: Sun, 25 Nov 2012 15:06:21 +0100 From: Pawel Jakub Dawidek To: Attilio Rao Subject: Re: [RFQ] make witness panic an option Message-ID: <20121125140620.GL1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> <20121125131252.GJ1460@garage.freebsd.pl> <20121125134743.GK1460@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7vAdt9JsdkkzRPKN" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 14:05:10 -0000 --7vAdt9JsdkkzRPKN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 25, 2012 at 01:48:23PM +0000, Attilio Rao wrote: > On Sun, Nov 25, 2012 at 1:47 PM, Pawel Jakub Dawidek wr= ote: > > On Sun, Nov 25, 2012 at 01:37:19PM +0000, Attilio Rao wrote: > >> On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek = wrote: > >> > On Sun, Nov 25, 2012 at 12:42:16PM +0000, Attilio Rao wrote: > >> >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek wrote: > >> >> > WITNESS is a development tool. We don't ship production kernels w= ith > >> >> > WITNESS even compiled in. What is more efficient use of developer= time: > >> >> > going through full reboot cycle every time or reading the warning= from > >> >> > console, unloading a module, fixing the bug and loading it again? > >> >> > > >> >> > And if this option is turned off by default what is the problem? > >> >> > >> >> Yes, so, why do you write here? > >> > > >> > I'm trying to understand why do you object. Until now the only conce= rn > >> > you have that I found is that you are afraid of it being abused. I d= on't > >> > see how this can be abused if it is turned off by default. If someone > >> > will commit a change that will turn it on by default, believe me, I'= ll > >> > unleash hell personally. > >> > >> So I don't understand what are you proposing. > >> You are not proposing to switch BLESSING on and you are not proposing > >> to import Adrian's patches in, if I get it correctly. I don't > >> understand then. > > > > I propose to get Adrian's patches in, just leave current behaviour as > > the default. >=20 > So if I tell that I'm afraid this mechanism will be abused (and > believe me, I really wanted to trimm out BLESSING stuff also for the > same reason) and you say "you can't see how" there is not much we can > discuss. This is not what I said. I would see it as abuse if someone will suddenly decided to turn off locking assertions by default in FreeBSD base. If he will turn that off on his private machine be it to speed up his development (a good thing) or to shut up important lock assertion (a bad thing) this is entirely his decision. He can already do that having all the source code, its just more complex. Make tools, not policies. BLESSING is totally different subject. You were afraid that people will start to silence LORs they don't understand by committing blessed pairs to FreeBSD base. And this situation is abuse and I fully agree, but I also still think BLESSING is useful, although I recognize it might be hard to prevent mentioned abuse. In case of Adrian's patch nothing will change in how we enforce locking assertions in FreeBSD base. > You know how I think, there is no need to wait for me to reconsider, > because I don't believe this will happen with arguments like "I don't > think", "I don't agree", etc. I provide valid arguments with I hope proper explanation, you choose not to address them or ignore them and I hope this will change:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --7vAdt9JsdkkzRPKN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCyJdwACgkQForvXbEpPzTHCACeMiM0zXHueZ1aJcdEX56NOsXP VskAoLbBLZH742DdygjBFTZYOpxAbHrz =Hya/ -----END PGP SIGNATURE----- --7vAdt9JsdkkzRPKN-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 14:09:02 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2C222EE; Sun, 25 Nov 2012 14:09:02 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id A45478FC08; Sun, 25 Nov 2012 14:09:01 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so7260452lbb.13 for ; Sun, 25 Nov 2012 06:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qZykcAZoW0RKyTdsvWkmXfPC1+4mvsyvaDFlNLBCB4k=; b=ixSSh9UNyvjl/RKLnTltCE+Ci5V7LczsCeFF6wEPt6YksJ8iE0dFOc4cZykoVj1meu TNBVkTwS7EGmnSeLBWBO1kr36e2Q5lPneE6KqZyFQnOuOoMpZf361xe6HhBSbbp4a96r t18i00lxJRSpjGhOIOAx1sKBosZ3n8+kFK+zd6WMpSt546pRpE0LBI+U3I3G8GofQnoT gQmhYiptEaOP84zHI3zZiHOZjqqM6qXVffro/VtmRlGa+DpOt/3pZaeoPQnOJem1WMfx F0DA2LLU1304HdbwsUDDHgR3aPWFfZv8AAslygYnz8AHKy6Ou/ZrC9E8IG003yCTgmfY qvAg== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr8189422lab.18.1353852540239; Sun, 25 Nov 2012 06:09:00 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sun, 25 Nov 2012 06:09:00 -0800 (PST) In-Reply-To: <20121125140620.GL1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> <20121125131252.GJ1460@garage.freebsd.pl> <20121125134743.GK1460@garage.freebsd.pl> <20121125140620.GL1460@garage.freebsd.pl> Date: Sun, 25 Nov 2012 14:09:00 +0000 X-Google-Sender-Auth: NgLPQcbFg0D9VZQzanBEbdILWZA Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 14:09:03 -0000 On Sun, Nov 25, 2012 at 2:06 PM, Pawel Jakub Dawidek wrote: > On Sun, Nov 25, 2012 at 01:48:23PM +0000, Attilio Rao wrote: >> On Sun, Nov 25, 2012 at 1:47 PM, Pawel Jakub Dawidek wrote: >> > On Sun, Nov 25, 2012 at 01:37:19PM +0000, Attilio Rao wrote: >> >> On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek wrote: >> >> > On Sun, Nov 25, 2012 at 12:42:16PM +0000, Attilio Rao wrote: >> >> >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek wrote: >> >> >> > WITNESS is a development tool. We don't ship production kernels with >> >> >> > WITNESS even compiled in. What is more efficient use of developer time: >> >> >> > going through full reboot cycle every time or reading the warning from >> >> >> > console, unloading a module, fixing the bug and loading it again? >> >> >> > >> >> >> > And if this option is turned off by default what is the problem? >> >> >> >> >> >> Yes, so, why do you write here? >> >> > >> >> > I'm trying to understand why do you object. Until now the only concern >> >> > you have that I found is that you are afraid of it being abused. I don't >> >> > see how this can be abused if it is turned off by default. If someone >> >> > will commit a change that will turn it on by default, believe me, I'll >> >> > unleash hell personally. >> >> >> >> So I don't understand what are you proposing. >> >> You are not proposing to switch BLESSING on and you are not proposing >> >> to import Adrian's patches in, if I get it correctly. I don't >> >> understand then. >> > >> > I propose to get Adrian's patches in, just leave current behaviour as >> > the default. >> >> So if I tell that I'm afraid this mechanism will be abused (and >> believe me, I really wanted to trimm out BLESSING stuff also for the >> same reason) and you say "you can't see how" there is not much we can >> discuss. > > This is not what I said. I would see it as abuse if someone will > suddenly decided to turn off locking assertions by default in FreeBSD > base. > > If he will turn that off on his private machine be it to speed up his > development (a good thing) or to shut up important lock assertion (a bad > thing) this is entirely his decision. He can already do that having all > the source code, its just more complex. Make tools, not policies. > > BLESSING is totally different subject. You were afraid that people will > start to silence LORs they don't understand by committing blessed pairs > to FreeBSD base. And this situation is abuse and I fully agree, but I > also still think BLESSING is useful, although I recognize it might be > hard to prevent mentioned abuse. > > In case of Adrian's patch nothing will change in how we enforce locking > assertions in FreeBSD base. > >> You know how I think, there is no need to wait for me to reconsider, >> because I don't believe this will happen with arguments like "I don't >> think", "I don't agree", etc. > > I provide valid arguments with I hope proper explanation, you choose not > to address them or ignore them and I hope this will change:) I'm not ignoring them, I'm saying that your arguments are not enough convincing to me. And really, giving the possibility to turn off assertions in witness is already a dangerous tool I want to avoid (not only related to BLESSING). If there are some cases that deserve a panic, we might just get it, not matter how sysctls are setup. However it seems to me I'm just saying the same thing since 20 e-mails, please drop me from CC in your next follow up. As I said, you can commit all the changes you want (assuming they are technically correct) even if I would appreciate my disagreement is expressed in the commit message. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 14:20:14 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C37FD60A; Sun, 25 Nov 2012 14:20:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 911C58FC08; Sun, 25 Nov 2012 14:20:13 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so9859159lah.13 for ; Sun, 25 Nov 2012 06:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cnNqoQPukRmNldxMx9UofAenoA3cai5nayBCAeWjFvo=; b=E0KfcDGGr+KQEZ/nPVcPELLb8AqrZn/f7EhpeQkoccD6FCqrJwsQXJ0i/UjkdMVTzx rG4xBoqzxPpTl2xp/+tQvr0H+nP/430Ti8oGVilHRO79oDvecUfax0ddv9bjIWx3dyjj rnvqU4fFeiK/ZNh++/3/3D04wAHCKOUEa0kydl8Lj0YqljIZ/UBHYT6UglKMSO08yN43 pti+hCgwBjZHTK3x00P9ToaHRnzx6VzFmCdji6ZqEg4Lz2QAHb3X7beRusWdcmDoUgy3 1yse8QlqaesAIC/dMisCeFnRYIpKF3Rr0vNK1hJ9CgQIn3xptssrxosX06hA9vk2Jgyq cA1Q== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr8223554lab.21.1353853212272; Sun, 25 Nov 2012 06:20:12 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Sun, 25 Nov 2012 06:20:12 -0800 (PST) In-Reply-To: <20121125131252.GJ1460@garage.freebsd.pl> References: <20121125123920.GI1460@garage.freebsd.pl> <20121125131252.GJ1460@garage.freebsd.pl> Date: Sun, 25 Nov 2012 14:20:12 +0000 X-Google-Sender-Auth: VIDSUp_4vKS6zzsIoSf3vrNnqRY Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 14:20:14 -0000 On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek wrote: > On Sun, Nov 25, 2012 at 12:42:16PM +0000, Attilio Rao wrote: >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek wrote: >> > WITNESS is a development tool. We don't ship production kernels with >> > WITNESS even compiled in. What is more efficient use of developer time: >> > going through full reboot cycle every time or reading the warning from >> > console, unloading a module, fixing the bug and loading it again? >> > >> > And if this option is turned off by default what is the problem? >> >> Yes, so, why do you write here? > > I'm trying to understand why do you object. Until now the only concern > you have that I found is that you are afraid of it being abused. I don't > see how this can be abused if it is turned off by default. If someone > will commit a change that will turn it on by default, believe me, I'll > unleash hell personally. > > As I said, WITNESS is development tool, a very handy one. This doesn't > mean we can't make it even more handy. It is there to help find bugs > faster, right? Adrian is proposing a change that will make it help to > find and fix bugs maybe even faster. > >> Go ahead and fix BLESSED, make it the default, etc. > > This is another story, but BLESSED is much less controversial to me. > It is turned off by default in assumption that all the code that runs in > our kernel is developed for FreeBSD, which is not true. For example ZFS > is, I think, the biggest locking consumer in our kernel (around 120 > locks), which wasn't originally developed for FreeBSD and locking order > was verified using different tools. Now on FreeBSD it triggers massive > LOR warnings from WITNESS, eventhough those are not bugs. At some point > I verified many of them and they were all false-positives, so I simply > turned off WITNESS warnings for ZFS locks. Why? Because BLESSED is > turned off in fear of abuse, and this is turn is the cause of mentioned > hack in ZFS. Just a few notes about this: to my knowledge you never discussed publically this. WITNESS is not a perfect tool and it has several issues (I tried to summarize them a bit at the beginning of this thread), where the biggest problem is that its file/line approach doesn't help when willing to shutdown specific LOR without shutting down all of them involving the lock pair, etc. I have no idea what are the problems you are facing here with WITNESS and ZFS but if you could summarize them we can work on getting something which is useful also with ZFS. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 19:11:26 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A6CD190; Sun, 25 Nov 2012 19:11:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B72E8FC12; Sun, 25 Nov 2012 19:11:25 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so4206905wey.13 for ; Sun, 25 Nov 2012 11:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jaWOUp1Jdih+C+0Q7IDmBiXQWbMd6Z387A5eZQsdeMg=; b=NAWZ9a90zYjLN6OQXwyfx408WlA5ybzHdtTCnzmONMxC/Uvdyn7KQbsnsAyZFix9fl DnEjQCF2o9IBMciq4L8OgLRzfncuPf7OorJ90HfGRdPYh3f381UxzXi6noXI0Yh0zwTw TNMxGlqj5FPb5olH/XoJ+zJzzV4DZLArEynyi5xxgqafSb6DKL9vzOE2kJRtVQfNsiUm Rs5bzxnA1kz22GYzQ8Jjjn1dnBwUaaP8Ja2N7djt+JcwJIQpW6QrIczHj64h2+KmnoGO KzkI4EjdqjXzblEiQj4Qw9u+oeUnYDTIonQ7diH5xGy1VlUYIAbQi6YZiKwE2N6Xm7ls hasQ== MIME-Version: 1.0 Received: by 10.180.103.106 with SMTP id fv10mr14050185wib.19.1353870684166; Sun, 25 Nov 2012 11:11:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 25 Nov 2012 11:11:24 -0800 (PST) In-Reply-To: References: <20121125123920.GI1460@garage.freebsd.pl> <20121125131252.GJ1460@garage.freebsd.pl> Date: Sun, 25 Nov 2012 11:11:24 -0800 X-Google-Sender-Auth: QleFQo76D6QpOTABeAxrWCaf1Fs Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 19:11:26 -0000 The reason I haven't yet committed it is I'd like to sit down with Attilio one-on-one and figure out the _right_ way to do this. There's a time for shit-stirring and a time for getting stuff done; this is neither of those times. I don't mind taking my time on this one. Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 19:18:58 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D73565B7 for ; Sun, 25 Nov 2012 19:18:58 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5AD8FC08 for ; Sun, 25 Nov 2012 19:18:57 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAPJIvwD050325 for ; Sun, 25 Nov 2012 12:18:57 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAPJItO6036431; Sun, 25 Nov 2012 12:18:55 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Porting linux drivers [was: Re: [RFC] sema_wait_sig] From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Nov 2012 12:18:55 -0700 Message-ID: <1353871135.69940.77.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 19:18:58 -0000 On Thu, 2012-11-22 at 22:12 -0800, Oleksandr Tymoshenko wrote: > Hello, > > Is there any particular reason FreeBSD does not have sema_wait_sig > function? It seems to be easily implementable using cv_wait_sig > function. > > The reason I'm asking is that I'm getting some Linux drivers > ported to FreeBSD and the code in question relies on semaphores > and there is no obvious alternative to down_interruptible function. > I realize that not all approaches to driver development are easily > mappable from OS to OS but in this case lack of cv_wait_sig seems > like gap in API. Unless of course there is strong rationale behind it. As if this thread weren't contentious enough already, it seems to me to be the perfect lead-in to a question I've long wondered about... Given that linux drivers are pretty much universally GPL licensed, what's the legality of "porting" them (whatever that means) to freebsd? Just how much can you cobble from a GPL'd linux driver in creating a BSD-licensed freebsd driver? I've done my best to avoid EVER looking at linux driver code when working on freebsd drivers, because I don't know the legalistic answers to such questions. I know the "what feels right to my moral sense" answer, which is if you study the linux driver and then write essentially the same driver for freebsd, it doesn't matter if you've re-typed the code with different variable names, you've copied it. I've peeked at the linux code from time to time, mostly to confirm my understanding of poorly-written chip datasheets, or to find the meaning of some status register bit that doesn't seem to be documented elsewhere. But it would be nice to know where the proper lines are that should not be crossed. -- Ian From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 20:14:45 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E236C46 for ; Sun, 25 Nov 2012 20:14:45 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3518FC0C for ; Sun, 25 Nov 2012 20:14:44 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TcibA-0009hM-6l; Sun, 25 Nov 2012 12:14:41 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Porting linux drivers [was: Re: [RFC] sema_wait_sig] From: Oleksandr Tymoshenko In-Reply-To: <1353871135.69940.77.camel@revolution.hippie.lan> Date: Sun, 25 Nov 2012 12:14:21 -0800 Content-Transfer-Encoding: 7bit Message-Id: <672A2D77-2BF7-41E1-8CAB-F199B8C8A5C1@bluezbox.com> References: <1353871135.69940.77.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-11-25, at 11:18 AM, Ian Lepore wrote: > On Thu, 2012-11-22 at 22:12 -0800, Oleksandr Tymoshenko wrote: >> Hello, >> >> Is there any particular reason FreeBSD does not have sema_wait_sig >> function? It seems to be easily implementable using cv_wait_sig >> function. >> >> The reason I'm asking is that I'm getting some Linux drivers >> ported to FreeBSD and the code in question relies on semaphores >> and there is no obvious alternative to down_interruptible function. >> I realize that not all approaches to driver development are easily >> mappable from OS to OS but in this case lack of cv_wait_sig seems >> like gap in API. Unless of course there is strong rationale behind it. > > As if this thread weren't contentious enough already, it seems to me to > be the perfect lead-in to a question I've long wondered about... > > Given that linux drivers are pretty much universally GPL licensed, > what's the legality of "porting" them (whatever that means) to freebsd? > Just how much can you cobble from a GPL'd linux driver in creating a > BSD-licensed freebsd driver? > > I've done my best to avoid EVER looking at linux driver code when > working on freebsd drivers, because I don't know the legalistic answers > to such questions. I know the "what feels right to my moral sense" > answer, which is if you study the linux driver and then write > essentially the same driver for freebsd, it doesn't matter if you've > re-typed the code with different variable names, you've copied it. > > I've peeked at the linux code from time to time, mostly to confirm my > understanding of poorly-written chip datasheets, or to find the meaning > of some status register bit that doesn't seem to be documented > elsewhere. But it would be nice to know where the proper lines are that > should not be crossed. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 20:14:45 -0000 On 2012-11-25, at 11:18 AM, Ian Lepore wrote: > On Thu, 2012-11-22 at 22:12 -0800, Oleksandr Tymoshenko wrote: >> Hello, >> >> Is there any particular reason FreeBSD does not have sema_wait_sig >> function? It seems to be easily implementable using cv_wait_sig >> function. >> >> The reason I'm asking is that I'm getting some Linux drivers >> ported to FreeBSD and the code in question relies on semaphores >> and there is no obvious alternative to down_interruptible function. >> I realize that not all approaches to driver development are easily >> mappable from OS to OS but in this case lack of cv_wait_sig seems >> like gap in API. Unless of course there is strong rationale behind it. > > As if this thread weren't contentious enough already, it seems to me to > be the perfect lead-in to a question I've long wondered about... > > Given that linux drivers are pretty much universally GPL licensed, > what's the legality of "porting" them (whatever that means) to freebsd? > Just how much can you cobble from a GPL'd linux driver in creating a > BSD-licensed freebsd driver? > > I've done my best to avoid EVER looking at linux driver code when > working on freebsd drivers, because I don't know the legalistic answers > to such questions. I know the "what feels right to my moral sense" > answer, which is if you study the linux driver and then write > essentially the same driver for freebsd, it doesn't matter if you've > re-typed the code with different variable names, you've copied it. > > I've peeked at the linux code from time to time, mostly to confirm my > understanding of poorly-written chip datasheets, or to find the meaning > of some status register bit that doesn't seem to be documented > elsewhere. But it would be nice to know where the proper lines are that > should not be crossed. Just to be clear - the drivers in question are going to be relicensed to BSD (actually, double-licensed) by upstream. And if it's not happening FreeBSD version will remain GPL. From owner-freebsd-arch@FreeBSD.ORG Tue Nov 27 07:12:42 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DA188DB for ; Tue, 27 Nov 2012 07:12:42 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9898FC13 for ; Tue, 27 Nov 2012 07:12:41 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so3368423dad.13 for ; Mon, 26 Nov 2012 23:12:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=sYThxsxlfEWqljoYptpHzGVPrex0nihl3AELYXH/DFk=; b=R/kTiQ6L34+jXHpF5WFcftlfK6u3D+gBfSU2oYdp7gP83UlL4umqrMcPbHOEqZIMN9 wyeqDcP7GLhBR2BqgRYy5JmuwrvWDIcfol1LvuTT5EEhnQfOoONsTEavb7KU1NJqYnnj 4Xzl4/SO62meBmL1aQxNYkkBjMHEseIdGxdM8rAalfcaqQcYByaBfUbiyWOzUMsie3Mq OSHR5CpI2MV7JgIltevtrClbQZxa0oM5Yz1Ny33nKd+9AR2lSVBnSg3po5akIthgSO/Z gq/qdkVT/+ob69+vdqrnrQYjEKxRyOagWKpMg3Z22CryIDQFng4+cRldbtjlDdfb03xa 730w== Received: by 10.68.247.196 with SMTP id yg4mr46175985pbc.167.1354000361523; Mon, 26 Nov 2012 23:12:41 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id x2sm2832017paw.8.2012.11.26.23.12.39 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 23:12:40 -0800 (PST) Date: Mon, 26 Nov 2012 21:11:37 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alfred Perlstein Subject: Re: [RFC] sema_wait_sig In-Reply-To: <50B187F2.2040506@mu.org> Message-ID: References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> <50B178A3.4070305@mu.org> <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> <50B17BF7.7020609@mu.org> <50B187F2.2040506@mu.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQlz0mFWx/uplil+GLQritwnJpsAxd1whndYWWfODuN5o4FiF7xYpzVLolmxUnzCZSeEH1+m Cc: "attilio@freebsd.org" , Mark Linimon , "arch@freebsd.org" , Oleksandr Tymoshenko X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 07:12:42 -0000 On Sat, 24 Nov 2012, Alfred Perlstein wrote: > On 11/24/12 6:22 PM, Daniel Eischen wrote: >> On Nov 24, 2012, at 9:01 PM, Alfred Perlstein wrote: >> >>> On 11/24/12 5:56 PM, Warner Losh wrote: >>>> On Nov 24, 2012, at 6:47 PM, Alfred Perlstein wrote: >>>> >>>>> 1) compat layer >>>>> /usr/src.local/sys/ofed/drivers/infiniband/core # >>>>> cddl/contrib/opensolaris >>>>> >>>>> 2) >>>>> if a user expects semaphores and we tell them to "rethink" things, then >>>>> we're not providing the same facilities as every other non-BSD OS. >>>>> >>>>> I guess that makes us "cool", but really it just seems out of touch. >>>>> >>>>> The implementation is 176 lines of code + some headers. >>>>> >>>>> The sad part to me is that the original user asked "hey I need >>>>> sema+signal" but we don't know the facility they really need, count of >>>>> 1? count of 10? instead of just giving them a textbook CS semaphore we >>>>> tell them to "build your own using our primitives". >>>> You don't need stdio, you can build it from the syscall primitives... >>> Dude, don't make me replace string.h/strncpy/strlcpy with sbuf_(9), cause >>> I will! >> Can we please chill? We're not talking about getting rid of a commonly >> used API with sema(9). We want to do what is right for FreeBSD, not Linux. >> That's not to say we can't have a Linux kernel compat shim or something, >> but they should be hidden accordingly and not used by native drivers and >> such. We definitely don't want every API for every OS, or we will become >> an amalgamation of those OSs. > Daniel, this is something that I really don't understand, a driver is a > driver, it's a means for putting packets on the wire or bytes on disk. There is a pretty large variation in how packets are put on the wire and how bytes are delivered to the disk. You can shim and wrap and emulate but in the end you don't end up with what's most efficient for the underlying operating system. I think that's the underlying issue here. We don't use semaphores, they aren't implemented well on FreeBSD. They are there as a token effort at providing an API that we felt was better served in other ways. If we want to support this API then we should support it well and it should be written to the standards of the other primitives. Attilio wants to solve the problem by eliminating the API entirely because he knows how long it takes to write a good primitive. Those who are calling to support it should consider the effort it takes. It's not free. Calling it supported rather than deprecated means driver authors will expect it to be up to the quality standards of the rest of the kernel. This could have unintended consequences. Idioms will be developed. Code will be copied and propagated. All while using something terribly inefficient. Users will wonder why their driver performs so much better on Linux. I am responsible for one use of this code and I only did so knowing that it wasn't for anything performance critical and I was being lazy with a considerable porting effort ahead of me. I think my approach at this point would be either to entirely eliminate sema or rewrite it appropriately. Adding new consumers and hacking in a new feature is just another half measure. Which of the other solutions is best is up to individual bias. > > Sometimes the stack becomes complicated due to topologies or interesting > features (hot plug), but in essence they are very much the same. > > I do not see the point of "FreeBSD'ing" a driver when we could share code > with another OS (infiniband?). It's just duplicate effort and makes it > harder to maintain. > > Sema is already used inside the sysv_ipc code. I don't understand the point > of trying to be different for the sake of differentness. It's really not done > us any favors. > > Our strength has been when we've surpassed the other OSes out there with > innovation: examples: cam, geom, kqueue, sendfile, accept filters, audit, > witness, vfs_debug, zfs. Our strength is not our different names for the > same things. Well I for one think we innovate in infrastructure as much as features and that innovation is important and necessarily means we can't always be compatible with everything else. We chose a locking and concurrency model that is not always compatible with everyone else and hopefully provides sufficient advantages to be preferable. Jeff > > I would certainly be accepting of a driver in FreeBSD that used sema(9) and I > think we should all, afterall our infiniband stack seems to, and that's kinda > cool. > > -Alfred > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 01:48:07 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96D04356 for ; Thu, 29 Nov 2012 01:48:07 +0000 (UTC) (envelope-from nocturneu854@jetstar.com) Received: from mail.csp-corp.com (mail.csp-corp.com [203.198.128.118]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD098FC08 for ; Thu, 29 Nov 2012 01:47:57 +0000 (UTC) Received: by 10.58.23.34 with SMTP id j2csp290522vef; Thu, 29 Nov 2012 09:48:00 +0800 Received: by 10.50.197.169 with SMTP id iv9mr3813833igc.32.1350718734043; Thu, 29 Nov 2012 09:48:00 +0800 Received-SPF: pass (google.com: domain of noreplyitineraries@jetstar.com designates 216.82.255.50 as permitted sender) client-ip=216.82.255.50; Authentication-Results: mx.google.com; spf=pass (google.com: domain of noreplyitineraries@jetstar.com designates 216.82.255.50 as permitted sender) smtp.mail=noreplyitineraries@jetstar.com X-Env-Sender: noreplyitineraries@jetstar.com X-StarScan-Version: 6.6.1.3; banners=jetstar.com,-,- X-VirusChecked: Checked Received: from unknown (HELO sydeqximr01.corp.jetstar.com) (168.134.2.42) by server-15.tower-143.messagelabs.com with SMTP; Thu, 29 Nov 2012 09:48:00 +0800 Received: from SYDEQXITN04 (sydeqxitn04.corp.jetstar.com [172.23.145.89]) by sydeqximr01.corp.jetstar.com (Postfix) with ESMTP id DA94058046 for <>; Thu, 29 Nov 2012 09:48:00 +0800 From: Jetstar To: Date: Thu, 29 Nov 2012 09:48:00 +0800 Subject: Jetstar Flight Itinerary Message-ID: <20121124355781.DA99240949@sydeqximr01.corp.jetstar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=a__kdcba_44_30_90" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 01:48:07 -0000 ------=a__kdcba_44_30_90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jetstar Flight Itinerary (Booking ref# RK5DPZ) bod= y, td{font-family:arial,sans-serif;font-size:13px} a:link, a:active {colo= r:#1155CC; text-decoration:none} a:hover {text-decoration:underline; curs= or: pointer} a:visited{color:##6611CC} img{border:0px} pre { white-space:= pre; white-space: -moz-pre-wrap; white-space: -o-pre-wrap; white-space: = pre-wrap; word-wrap: break-word; width: 800px; overflow: auto;} = = Thu, 29 Nov 2012 09:48:00 +0800 = = = = = = = = = = = Your= self Check-in Details are attached = = = = = = Booking Reference = = D1ISW6 = = = = = = = = = = = = = This is not a Boarding Pa= ss = = = Your Itinerary is attached as file to p= rint = = = = = = = = Unsubscribe from Jet= star Marketing Communications = = = Baggage = Cabin Baggage = = = Your main item must not exceed the dimensions below = = = = = = Flight = Height = Width = Depth = = = JQ, 3K, VF, GK = 56cm = 36cm 23cm = = = Carry-on Bag = = = = = Flight = Height = Width = Depth = = = JQ, 3K, VF, GK = 114cm = 60cm 11cm = = = Suit Pack- non rigid = = = = If your cabin baggage exce= eds any of these limits, you may be required to check in your baggage and= significant fees may apply.Your allowance:Economy Starter fares (includi= ng Starter Plus and Starter Max): 1 main piece of Cabin Baggage and one s= mall item up to a maximum total combined weight of 10kg for each passenge= r for JQ/3K/VF/GK, or 7kg for BL operated flights.Business fares (includi= ng Business Max fares): 2 main pieces of Cabin Baggage and one small item= for each passenger ,provided that each main item does not exceed 10kg, w= ith a total combined Cabin Baggage weight of up to 20kg.All Small items m= ust fit under the seat in front of you and may be one of the following it= ems: small handbag, pocket book or purse, coat, umbrella or laptop. Infan= ts do not have a baggage allowance if they do not occupy a paid seat. Jet= star will carry strollers/prams and allow food/consumables for in-flight = use for any infants/small children free of charge. = = = Checked Baggage = = Any one bag must not weigh more than 32kg or be higher th= an the dimensions below = = = = = = Flight = Height = = A320, A321, B737 = 190cm (6'3) = = The ty= pe of aircraft operating your flight can be found in your flight details = above. Not all fares include a checked baggage allowance, see flight deta= ils above for details of each passengers allowance. = = = = Fare Rules = Your flights are governed by the particular far= e rules of each selected fare. The fare rules give key information as to = if and when the booking is refundable, what changes are permitted and wit= hin what timeframe, and other key information you are required to know.Th= e selected fare for each flight can be found in Flight Details above. = Click to view your full fare rules = = = = Further Important Informat= ion Click here to view further i= nformation regarding your booking and flight with Jetstar, such as furthe= r baggage information, health requirements security information and in-fl= ight product. = = = Conditions of Carriage = Your travel is subject to the Jetst= ar Conditions of Carriage. Some of the applicable key conditions of carri= age are provided in the link below. The full Conditions of Carriage are a= vailable at the airport or on jetstar.com. If your journey is to another = country, the Montreal or Warsaw Convention may govern and limit liability= for death or injury and for loss of or delay or damage to baggage. For m= ore info view the link below. Vi= ew Jetstar key conditions of carriage = = = No Flight Connections = Unless you have been advised otherwi= se by Jetstar, you must collect your Checked Baggage after each individua= l flight. It is the Passenger's responsibility when making Bookings to al= low time for Baggage collection and recheck and terminal transfer if requ= ired. Please see our Ԕravel InfoԠsection of Jetstar.com, and = refer to our ԁt the AirportԠpage for further information. Tra= vel insurance is recommended. Jetstar does not guarantee it will be able = to carry you and your Baggage in accordance with the scheduled date and t= ime of the flights specified. Schedules may change without notice for a r= ange of reasons including but not limited to bad weather, air traffic con= trol delays, strikes, technical disruptions and late inbound aircraft. Un= less otherwise required by law, we will not be responsible for paying any= costs or expenses you may incur as a result of the changed time or cance= llation. = = = For all other details visit our Customer Service Page = = Jetstar= Airways Pty. Ltd.GPO Box 4713Melbourne VIC 3001AUSTRALIAABN: 33 069 720 = 243Travel Agents Licence Number VIC32696 = T= his e-mail is intended only to be read or used by the addressee. It is co= nfidential and may contain legally privileged information. If you are not= the addressee indicated in this message (or responsible for delivery of = the message to such person), you may not copy or deliver this message to = anyone, and you should destroy this message and kindly notify the sender = by reply e-mail. Confidentiality and legal privilege are not waived or lo= st by reason of mistaken delivery to you. = Jetstar Airways Pty Limited ABN = 33 069 720 243 = = ------=a__kdcba_44_30_90-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 07:38:31 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F150C1D4; Thu, 29 Nov 2012 07:38:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ABE9F8FC14; Thu, 29 Nov 2012 07:38:31 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C9E2E46B17; Thu, 29 Nov 2012 02:38:30 -0500 (EST) Date: Thu, 29 Nov 2012 07:38:30 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson Subject: Re: [RFC] sema_wait_sig In-Reply-To: Message-ID: References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> <50B178A3.4070305@mu.org> <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> <50B17BF7.7020609@mu.org> <50B187F2.2040506@mu.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "attilio@freebsd.org" , Mark Linimon , Alfred Perlstein , Oleksandr Tymoshenko , "arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 07:38:32 -0000 On Mon, 26 Nov 2012, Jeff Roberson wrote: > I think that's the underlying issue here. We don't use semaphores, they > aren't implemented well on FreeBSD. They are there as a token effort at > providing an API that we felt was better served in other ways. If we want > to support this API then we should support it well and it should be written > to the standards of the other primitives. > > Attilio wants to solve the problem by eliminating the API entirely because > he knows how long it takes to write a good primitive. Those who are calling > to support it should consider the effort it takes. It's not free. Calling > it supported rather than deprecated means driver authors will expect it to > be up to the quality standards of the rest of the kernel. This could have > unintended consequences. Idioms will be developed. Code will be copied and > propagated. All while using something terribly inefficient. Users will > wonder why their driver performs so much better on Linux. > > I am responsible for one use of this code and I only did so knowing that it > wasn't for anything performance critical and I was being lazy with a > considerable porting effort ahead of me. I think my approach at this point > would be either to entirely eliminate sema or rewrite it appropriately. > Adding new consumers and hacking in a new feature is just another half > measure. Which of the other solutions is best is up to individual bias. I had originally followed up on Jeff's comment privately, but probably would have been more useful to do so publically -- I'm a bit late to the discussion, but: FWIW, I quite agree with these points -- I'd hoped sema(9) would go away years ago, since its underuse has a number of implications: (1) Poor integration with debugging support -- e.g., WITNESS, profiling, etc. These features make a huge difference in our development model, effectively preventing us from shipping many common forms of deadlock in the field at all, but come at significant initial cost in developing the underlying locking primitives. sema(9) is an abandoned step child and should not persist in its current state. (2) Poor optimisation -- the great work folk like John and Attilio have done on adaptive locking support, etc, massively improved performance in the 6.x and 7.x timeframe, addressing necessary contention much more efficiently. The reality is that contention occurs frequently because communication occurs frequently; obviously, we try to use work distribution, improved lock granularity, etc, where we can, but sometimes you must communicate and you can't use lockless primitives, so locks need to be fast under contention, not just when uncontended. (3) Not fitting our general design choice of aligning synchronisation primitives with POSIX -- a particularly important design choice in pthreads is not conflating mutual exclusion (locks) with process synchronisation (condition variables). This semantic distinction improves our ability to use static and dynamic analysis (e.g., WITNESS, static lock order checking), but also affects our ability to offer priority propagation. We could try and fix this in semaphores by providing more intent information (SEM_THIS_IS_A_MUTEX, SEM_THIS_IS_A_CONDVAR) but at that point I think we're much better off using the existing mutex, rwlock, and condition variable primitives directly, which gives us the information via C types. The main reason sema(9) didn't go away was its use in our old ATA code; this is something that can and should be fixed, and the new ATA code does not take that perspective. While I have no plans to do so myself, I'd be quite supportive of garbage collecting sema(9) in favour of requiring minor modifications to driver ports in order to better distinguish mutual exclusion and synchronisation, allowing WITNESS and other tools to properly analyse the behavior of imported code, and also to support future use of static analysis (e.g., the maturing Clang static lock analyser). The only recent code I'm aware of to start using sema(9) is the Infiniband work you did; if you feel that it's not a significant burden to adapt it to use the native synchronisation primitives, then the main structural obstacle to moving away from sema(9) is eliminated. Robert From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 09:00:26 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E97C9879 for ; Thu, 29 Nov 2012 09:00:26 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id AB40A8FC16 for ; Thu, 29 Nov 2012 09:00:26 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 150968A6 for ; Thu, 29 Nov 2012 09:58:35 +0100 (CET) Date: Thu, 29 Nov 2012 10:01:47 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Subject: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129090147.GB1370@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5/uDoXvLw7AC5HRs" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 09:00:27 -0000 --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'd like to propose the following patch: http://people.freebsd.org/~pjd/patches/uma_warning.patch When UMA zone is created, one can add configure a warning that should be printed when UMA zone is full by calling: uma_zone_set_warning(socket_zone, "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); It was very easy to find and fix the problem when I saw messages on the console that kern.maxfiles limit is reached, but when I hit kern.ipc.maxsockets limit and started to get ENOBUFS errors it took me a while to figure out what to tune. This patch allows to configure advice for the use and give him some details in a very easy way. The warning printed on the console is rate-limited to one per second. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC3JHoACgkQForvXbEpPzQYdQCeNcKAq2lwpHOz1VXG4Cr3y/nJ axwAoNCcCug/m+13v663UhRhkqB83Gwy =MnFT -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 09:40:29 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 879831D8; Thu, 29 Nov 2012 09:40:29 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6498FC0C; Thu, 29 Nov 2012 09:40:29 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id D25571A3C2C; Thu, 29 Nov 2012 01:40:28 -0800 (PST) Message-ID: <50B72D8C.7040201@mu.org> Date: Thu, 29 Nov 2012 01:40:28 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Print a (rate-limited) warning when UMA zone is full. References: <20121129090147.GB1370@garage.freebsd.pl> In-Reply-To: <20121129090147.GB1370@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 09:40:29 -0000 On 11/29/12 1:01 AM, Pawel Jakub Dawidek wrote: > Hi. > > I'd like to propose the following patch: > > http://people.freebsd.org/~pjd/patches/uma_warning.patch > > When UMA zone is created, one can add configure a warning that should be > printed when UMA zone is full by calling: > > uma_zone_set_warning(socket_zone, > "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); > > It was very easy to find and fix the problem when I saw messages on the > console that kern.maxfiles limit is reached, but when I hit > kern.ipc.maxsockets limit and started to get ENOBUFS errors it took me a > while to figure out what to tune. > > This patch allows to configure advice for the use and give him some > details in a very easy way. The warning printed on the console is > rate-limited to one per second. > This is great. Please commit this as soon as you can. An MFC would be awesome. -Alfred From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:30:09 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B2F4E21; Thu, 29 Nov 2012 10:30:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E43B78FC15; Thu, 29 Nov 2012 10:30:08 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 098DC46B2A; Thu, 29 Nov 2012 05:30:08 -0500 (EST) Date: Thu, 29 Nov 2012 10:30:07 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek Subject: Re: Print a (rate-limited) warning when UMA zone is full. In-Reply-To: <20121129090147.GB1370@garage.freebsd.pl> Message-ID: References: <20121129090147.GB1370@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:30:09 -0000 On Thu, 29 Nov 2012, Pawel Jakub Dawidek wrote: > I'd like to propose the following patch: > > http://people.freebsd.org/~pjd/patches/uma_warning.patch > > When UMA zone is created, one can add configure a warning that should be > printed when UMA zone is full by calling: > > uma_zone_set_warning(socket_zone, > "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); > > It was very easy to find and fix the problem when I saw messages on the > console that kern.maxfiles limit is reached, but when I hit > kern.ipc.maxsockets limit and started to get ENOBUFS errors it took me a > while to figure out what to tune. > > This patch allows to configure advice for the use and give him some details > in a very easy way. The warning printed on the console is rate-limited to > one per second. Just to follow up on some out-of-band communication -- this is a good idea, but there was some concern about printf() under mutexes. I'm not actually that concerned about that case (we do it quite a lot for warnings and kernel debugging), but it might be useful to consider using log() instead, so that it ends up in the system log as well as on the console. For I while I've wondered if we need a spp to complement pps -- that is, limiting printf()s to every (n) seconds, rather than (n) per second. For tunable warnings like this, it would be nice to limit them to once a minute or similar. Finally, we should make sure that in all instances where we point at tuning(7), it has something useful to say about the topic :-). Robert From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:36:33 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A431EF9E; Thu, 29 Nov 2012 10:36:33 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6260F8FC08; Thu, 29 Nov 2012 10:36:32 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id C87958D1; Thu, 29 Nov 2012 11:34:40 +0100 (CET) Date: Thu, 29 Nov 2012 11:37:52 +0100 From: Pawel Jakub Dawidek To: Robert Watson Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129103752.GD1370@garage.freebsd.pl> References: <20121129090147.GB1370@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RhUH2Ysw6aD5utA4" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:36:33 -0000 --RhUH2Ysw6aD5utA4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 29, 2012 at 10:30:07AM +0000, Robert Watson wrote: >=20 > On Thu, 29 Nov 2012, Pawel Jakub Dawidek wrote: >=20 > > I'd like to propose the following patch: > > > > http://people.freebsd.org/~pjd/patches/uma_warning.patch > > > > When UMA zone is created, one can add configure a warning that should b= e=20 > > printed when UMA zone is full by calling: > > > > uma_zone_set_warning(socket_zone, > > "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); > > > > It was very easy to find and fix the problem when I saw messages on the= =20 > > console that kern.maxfiles limit is reached, but when I hit=20 > > kern.ipc.maxsockets limit and started to get ENOBUFS errors it took me = a=20 > > while to figure out what to tune. > > > > This patch allows to configure advice for the use and give him some det= ails=20 > > in a very easy way. The warning printed on the console is rate-limited = to=20 > > one per second. >=20 > Just to follow up on some out-of-band communication -- this is a good ide= a,=20 > but there was some concern about printf() under mutexes. I'm not actuall= y=20 > that concerned about that case (we do it quite a lot for warnings and ker= nel=20 > debugging), but it might be useful to consider using log() instead, so th= at it=20 > ends up in the system log as well as on the console. I'm happy with using log(9), but currently when log(9) is used, the message is not printed on the console, it only ends up in the system log. printf(9) on the other hand is printed on the console and is appended to the system logs. The only case where log(9) will actually log to the console, AFAIR, is when syslogd is not working. > For I while I've wondered if we need a spp to complement pps -- that is,= =20 > limiting printf()s to every (n) seconds, rather than (n) per second. For= =20 > tunable warnings like this, it would be nice to limit them to once a minu= te or=20 > similar. Or change pps to ppm. I agree that getting these warning every second is too aggressive. > Finally, we should make sure that in all instances where we point at=20 > tuning(7), it has something useful to say about the topic :-). Yes, I am aware the warnings proposed in the patch are a bit too optimistic:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --RhUH2Ysw6aD5utA4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC3OwAACgkQForvXbEpPzQfigCfWcBL+1DTzY0w9Co2AWNZnjDs LNkAoK53E5T30vGbsIRdJhC7lV3tQcZ9 =N8rI -----END PGP SIGNATURE----- --RhUH2Ysw6aD5utA4-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:44:25 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61622285; Thu, 29 Nov 2012 10:44:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 333A98FC12; Thu, 29 Nov 2012 10:44:25 +0000 (UTC) Received: from [192.168.2.119] (host86-146-118-26.range86-146.btcentralplus.com [86.146.118.26]) by cyrus.watson.org (Postfix) with ESMTPSA id 5C3C546B0C; Thu, 29 Nov 2012 05:44:24 -0500 (EST) Subject: Re: Print a (rate-limited) warning when UMA zone is full. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20121129103752.GD1370@garage.freebsd.pl> Date: Thu, 29 Nov 2012 10:44:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:44:25 -0000 On 29 Nov 2012, at 10:37, Pawel Jakub Dawidek wrote: >> Just to follow up on some out-of-band communication -- this is a good = idea,=20 >> but there was some concern about printf() under mutexes. I'm not = actually=20 >> that concerned about that case (we do it quite a lot for warnings and = kernel=20 >> debugging), but it might be useful to consider using log() instead, = so that it=20 >> ends up in the system log as well as on the console. >=20 > I'm happy with using log(9), but currently when log(9) is used, the > message is not printed on the console, it only ends up in the system > log. printf(9) on the other hand is printed on the console and is > appended to the system logs. >=20 > The only case where log(9) will actually log to the console, AFAIR, is > when syslogd is not working. >=20 >> For I while I've wondered if we need a spp to complement pps -- that = is,=20 >> limiting printf()s to every (n) seconds, rather than (n) per second. = For=20 >> tunable warnings like this, it would be nice to limit them to once a = minute or=20 >> similar. >=20 > Or change pps to ppm. I agree that getting these warning every second = is > too aggressive. It does sound like the underlying primitives require some tweaking of = we're going to increase their use in the ways proposed. This is probably = overdue anyway. >> Finally, we should make sure that in all instances where we point at=20= >> tuning(7), it has something useful to say about the topic :-). >=20 > Yes, I am aware the warnings proposed in the patch are a bit too > optimistic:) The other fix, of course, is not to refer to tuning(7) :-). In general, providing feedback on tuning problems is a very good idea, = and something we should do more of. We should also continue to improve = our auto-tuning so that users see the warnings only infrequently. Robert= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:51:46 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FB324B4; Thu, 29 Nov 2012 10:51:46 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id B719E8FC13; Thu, 29 Nov 2012 10:51:45 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 0919F8D9; Thu, 29 Nov 2012 11:49:53 +0100 (CET) Date: Thu, 29 Nov 2012 11:53:06 +0100 From: Pawel Jakub Dawidek To: "Robert N. M. Watson" Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129105306.GE1370@garage.freebsd.pl> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AsxXAMtlQ5JHofzM" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:51:46 -0000 --AsxXAMtlQ5JHofzM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 29, 2012 at 10:44:22AM +0000, Robert N. M. Watson wrote: >=20 > On 29 Nov 2012, at 10:37, Pawel Jakub Dawidek wrote: >=20 > >> Just to follow up on some out-of-band communication -- this is a good = idea,=20 > >> but there was some concern about printf() under mutexes. I'm not actu= ally=20 > >> that concerned about that case (we do it quite a lot for warnings and = kernel=20 > >> debugging), but it might be useful to consider using log() instead, so= that it=20 > >> ends up in the system log as well as on the console. > >=20 > > I'm happy with using log(9), but currently when log(9) is used, the > > message is not printed on the console, it only ends up in the system > > log. printf(9) on the other hand is printed on the console and is > > appended to the system logs. > >=20 > > The only case where log(9) will actually log to the console, AFAIR, is > > when syslogd is not working. > >=20 > >> For I while I've wondered if we need a spp to complement pps -- that i= s,=20 > >> limiting printf()s to every (n) seconds, rather than (n) per second. = For=20 > >> tunable warnings like this, it would be nice to limit them to once a m= inute or=20 > >> similar. > >=20 > > Or change pps to ppm. I agree that getting these warning every second is > > too aggressive. >=20 > It does sound like the underlying primitives require some tweaking of we'= re going to increase their use in the ways proposed. This is probably overd= ue anyway. So what do you think about adding ppmratecheck() next to ppsratecheck()? If a bigger change is required that will change ppsratecheck() KPI, then I'd also like to create a structure to hide 'struct timeval lastfail' and 'int curfail', eg: struct ratecheck { struct timeval rc_lastfail; int rc_curfail; }; And use this with the new ppsratecheck(). > >> Finally, we should make sure that in all instances where we point at= =20 > >> tuning(7), it has something useful to say about the topic :-). > >=20 > > Yes, I am aware the warnings proposed in the patch are a bit too > > optimistic:) >=20 > The other fix, of course, is not to refer to tuning(7) :-). This is the optimistic part I was referring to - you can't find much in tuning(7) about those sysctls/tunables. > In general, providing feedback on tuning problems is a very good idea, an= d something we should do more of. We should also continue to improve our au= to-tuning so that users see the warnings only infrequently. Agreed, especially if reaching those limits is expected by the administrator and he is not going to increase them. But in this case it would be even better to provide a way to turn them off. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --AsxXAMtlQ5JHofzM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC3PpIACgkQForvXbEpPzSnZwCg711l4bXK7vu4VnQfu82poo+c mqoAniNqu4DFinzuP4Q3b5PAApRjiauH =vOxs -----END PGP SIGNATURE----- --AsxXAMtlQ5JHofzM-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 10:56:35 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90173591; Thu, 29 Nov 2012 10:56:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E53E8FC14; Thu, 29 Nov 2012 10:56:35 +0000 (UTC) Received: from [192.168.2.119] (host86-146-118-26.range86-146.btcentralplus.com [86.146.118.26]) by cyrus.watson.org (Postfix) with ESMTPSA id 8119846B0C; Thu, 29 Nov 2012 05:56:34 -0500 (EST) Subject: Re: Print a (rate-limited) warning when UMA zone is full. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20121129105306.GE1370@garage.freebsd.pl> Date: Thu, 29 Nov 2012 10:56:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> <20121129105306.GE1370@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:56:35 -0000 On 29 Nov 2012, at 10:53, Pawel Jakub Dawidek wrote: >> It does sound like the underlying primitives require some tweaking of = we're going to increase their use in the ways proposed. This is probably = overdue anyway. >=20 > So what do you think about adding ppmratecheck() next to = ppsratecheck()? >=20 > If a bigger change is required that will change ppsratecheck() KPI, = then > I'd also like to create a structure to hide 'struct timeval lastfail' > and 'int curfail', eg: >=20 > struct ratecheck { > struct timeval rc_lastfail; > int rc_curfail; > }; >=20 > And use this with the new ppsratecheck(). Sounds good to me. >>>> Finally, we should make sure that in all instances where we point = at=20 >>>> tuning(7), it has something useful to say about the topic :-). >>>=20 >>> Yes, I am aware the warnings proposed in the patch are a bit too >>> optimistic:) >>=20 >> The other fix, of course, is not to refer to tuning(7) :-). >=20 > This is the optimistic part I was referring to - you can't find much = in > tuning(7) about those sysctls/tunables. >=20 >> In general, providing feedback on tuning problems is a very good = idea, and something we should do more of. We should also continue to = improve our auto-tuning so that users see the warnings only = infrequently. >=20 > Agreed, especially if reaching those limits is expected by the > administrator and he is not going to increase them. But in this case = it > would be even better to provide a way to turn them off. I wonder if each instance of a 'ratecheck' should come with an = associated tunable/sysctl pair to allow suppression to be easily = configured. I almost find myself wondering if we want something that = looks a bit like our static SYSCTL/VFS_SET/etc declarations: static RATECHECK(..., "foo.bar.baz", ...); Unfortunately, the tunable/sysctl mismatch makes it slightly awkward = since you'd need to declare both, but I think probably worthwhile. Robert= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 11:03:58 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14F5088A; Thu, 29 Nov 2012 11:03:58 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id BE85E8FC08; Thu, 29 Nov 2012 11:03:57 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 1D3D58E1; Thu, 29 Nov 2012 12:02:06 +0100 (CET) Date: Thu, 29 Nov 2012 12:05:18 +0100 From: Pawel Jakub Dawidek To: "Robert N. M. Watson" Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129110518.GF1370@garage.freebsd.pl> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> <20121129105306.GE1370@garage.freebsd.pl> <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DEueqSqTbz/jWVG1" Content-Disposition: inline In-Reply-To: <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:03:58 -0000 --DEueqSqTbz/jWVG1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 29, 2012 at 10:56:32AM +0000, Robert N. M. Watson wrote: > On 29 Nov 2012, at 10:53, Pawel Jakub Dawidek wrote: > > Agreed, especially if reaching those limits is expected by the > > administrator and he is not going to increase them. But in this case it > > would be even better to provide a way to turn them off. >=20 > I wonder if each instance of a 'ratecheck' should come with an associated= tunable/sysctl pair to allow suppression to be easily configured. I almost= find myself wondering if we want something that looks a bit like our stati= c SYSCTL/VFS_SET/etc declarations: >=20 > static RATECHECK(..., "foo.bar.baz", ...); >=20 > Unfortunately, the tunable/sysctl mismatch makes it slightly awkward sinc= e you'd need to declare both, but I think probably worthwhile. I'm afraid you lost me here. Tunable/sysctl name is not related in any way with the warning we are printing. How can you tell kern.ipc.maxsockets affects limits of eight different UMA zones? Also rate-limiting is not only used to print warnings, current ppsratecheck() function just answer the question if the limit should be enforced (something is happening too frequently) or not. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --DEueqSqTbz/jWVG1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC3QW0ACgkQForvXbEpPzSulgCfRCPHzNfLeckghq92LSthW13d e6IAn3EkeJUrm3uCBZl0LD0XGnT5qBm/ =2pUI -----END PGP SIGNATURE----- --DEueqSqTbz/jWVG1-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 11:35:11 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6F62EA3; Thu, 29 Nov 2012 11:35:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC598FC14; Thu, 29 Nov 2012 11:35:10 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qATBZ34A054786; Thu, 29 Nov 2012 13:35:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qATBZ34A054786 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qATBZ3gi054785; Thu, 29 Nov 2012 13:35:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Nov 2012 13:35:03 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129113503.GD3013@kib.kiev.ua> References: <20121129090147.GB1370@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OzigliFs3e0dNr73" Content-Disposition: inline In-Reply-To: <20121129090147.GB1370@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:35:11 -0000 --OzigliFs3e0dNr73 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 29, 2012 at 10:01:47AM +0100, Pawel Jakub Dawidek wrote: > Hi. >=20 > I'd like to propose the following patch: >=20 > http://people.freebsd.org/~pjd/patches/uma_warning.patch >=20 > When UMA zone is created, one can add configure a warning that should be > printed when UMA zone is full by calling: >=20 > uma_zone_set_warning(socket_zone, > "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); >=20 > It was very easy to find and fix the problem when I saw messages on the > console that kern.maxfiles limit is reached, but when I hit > kern.ipc.maxsockets limit and started to get ENOBUFS errors it took me a > while to figure out what to tune. >=20 > This patch allows to configure advice for the use and give him some > details in a very easy way. The warning printed on the console is > rate-limited to one per second. I cannot comment on the addition of the fields to struct uma_zone. But please, can you drop the silly 'see tuning(7)' bytes ? --OzigliFs3e0dNr73 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC3SGcACgkQC3+MBN1Mb4i51QCfcDBoJmETtivxWM+bNCk7SI/t 7vwAoKI7GUumAXtTxSmrkHm/y+XwLdIa =kScx -----END PGP SIGNATURE----- --OzigliFs3e0dNr73-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 11:42:35 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6481FA3; Thu, 29 Nov 2012 11:42:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 854CF8FC08; Thu, 29 Nov 2012 11:42:35 +0000 (UTC) Received: from c0205.aw.cl.cam.ac.uk (c0205.aw.cl.cam.ac.uk [128.232.100.205]) by cyrus.watson.org (Postfix) with ESMTPSA id 74FF046B09; Thu, 29 Nov 2012 06:42:34 -0500 (EST) Subject: Re: Print a (rate-limited) warning when UMA zone is full. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20121129110518.GF1370@garage.freebsd.pl> Date: Thu, 29 Nov 2012 11:42:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <98FCA89B-D1DF-4002-B44F-A59DCB5ED020@FreeBSD.org> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> <20121129105306.GE1370@garage.freebsd.pl> <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> <20121129110518.GF1370@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:42:35 -0000 On 29 Nov 2012, at 11:05, Pawel Jakub Dawidek wrote: > On Thu, Nov 29, 2012 at 10:56:32AM +0000, Robert N. M. Watson wrote: >> On 29 Nov 2012, at 10:53, Pawel Jakub Dawidek wrote: >>> Agreed, especially if reaching those limits is expected by the >>> administrator and he is not going to increase them. But in this case = it >>> would be even better to provide a way to turn them off. >>=20 >> I wonder if each instance of a 'ratecheck' should come with an = associated tunable/sysctl pair to allow suppression to be easily = configured. I almost find myself wondering if we want something that = looks a bit like our static SYSCTL/VFS_SET/etc declarations: >>=20 >> static RATECHECK(..., "foo.bar.baz", ...); >>=20 >> Unfortunately, the tunable/sysctl mismatch makes it slightly awkward = since you'd need to declare both, but I think probably worthwhile. >=20 > I'm afraid you lost me here. Tunable/sysctl name is not related in any > way with the warning we are printing. How can you tell > kern.ipc.maxsockets affects limits of eight different UMA zones? > Also rate-limiting is not only used to print warnings, current > ppsratecheck() function just answer the question if the limit should = be > enforced (something is happening too frequently) or not. I meant something a bit different -- I was concerned with a per-instance = sysctl/tunable to silence the warnings. For embedded systems or systems = running at peak load, occasional allocation failures may be the steady = state, in which case tuning down the rate of message printing, or simply = disabling them rather than spamming logs, may be desirable. Robert= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 15:37:37 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FE1F77F; Thu, 29 Nov 2012 15:37:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2A44F8FC08; Thu, 29 Nov 2012 15:37:34 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qATFbQDk006278; Thu, 29 Nov 2012 08:37:27 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qATFbOLX041205; Thu, 29 Nov 2012 08:37:24 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Print a (rate-limited) warning when UMA zone is full. From: Ian Lepore To: "Robert N. M. Watson" In-Reply-To: <98FCA89B-D1DF-4002-B44F-A59DCB5ED020@FreeBSD.org> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> <20121129105306.GE1370@garage.freebsd.pl> <0D8E588B-6FCB-4B01-9786-B5D42F16C3F0@FreeBSD.org> <20121129110518.GF1370@garage.freebsd.pl> <98FCA89B-D1DF-4002-B44F-A59DCB5ED020@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Nov 2012 08:37:24 -0700 Message-ID: <1354203444.69940.205.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 15:37:37 -0000 On Thu, 2012-11-29 at 11:42 +0000, Robert N. M. Watson wrote: > On 29 Nov 2012, at 11:05, Pawel Jakub Dawidek wrote: > > > On Thu, Nov 29, 2012 at 10:56:32AM +0000, Robert N. M. Watson wrote: > >> On 29 Nov 2012, at 10:53, Pawel Jakub Dawidek wrote: > >>> Agreed, especially if reaching those limits is expected by the > >>> administrator and he is not going to increase them. But in this case it > >>> would be even better to provide a way to turn them off. > >> > >> I wonder if each instance of a 'ratecheck' should come with an associated tunable/sysctl pair to allow suppression to be easily configured. I almost find myself wondering if we want something that looks a bit like our static SYSCTL/VFS_SET/etc declarations: > >> > >> static RATECHECK(..., "foo.bar.baz", ...); > >> > >> Unfortunately, the tunable/sysctl mismatch makes it slightly awkward since you'd need to declare both, but I think probably worthwhile. > > > > I'm afraid you lost me here. Tunable/sysctl name is not related in any > > way with the warning we are printing. How can you tell > > kern.ipc.maxsockets affects limits of eight different UMA zones? > > Also rate-limiting is not only used to print warnings, current > > ppsratecheck() function just answer the question if the limit should be > > enforced (something is happening too frequently) or not. > > I meant something a bit different -- I was concerned with a per-instance sysctl/tunable to silence the warnings. For embedded systems or systems running at peak load, occasional allocation failures may be the steady state, in which case tuning down the rate of message printing, or simply disabling them rather than spamming logs, may be desirable. > > Robert I've been pondering the problem of rating-limiting error spewage and automatic retry attempts on embedded systems for a long time. Recently I got around to writing something to deal with it. What I wrote is implemented as a C++ class, but it would translate to C code using a struct and a couple related functions without too much trouble if there's interest. Extracted from the comment block describing it in the header file... RateLimiter (See MTRateLimiter below for a thread-safe version). This helps you limit some action to "once every N seconds" with the option to specify multiple values of N so that the interval between actions increases over time. It's especially useful to throttle error logging and error recovery attempts. If you specify a single interval, this class functions as a simple "once every N seconds" filter, where RateCheck() returns true if it has been N seconds or more since it last returned true. Boring. The interesting part is that you can provide a series of increasing interval values so that the action becomes less frequent over time. This can be especially useful for logging error conditions that are sometimes transient and sometimes go on for a long time. For example, if you have code that polls hardware status once a second and logs any problems it finds, then you probably don't want to log once per second for as long as the problem lasts. On the other hand, you don't want to log it just once and hope someone sees that one crucial line in the log amongst all the other spewage that may be happening when there's some sort of problem going on. When a problem first occurs it's worth mentioning often, maybe once a minute. If the problem is still happening 15 minutes later then maybe once every 15 minutes is often enough. But if the problem is still there after 12 hours, then mentioning it just a couple times a day from that point on is good enough. This class lets you manage that by setting the intervals to 60, 900, 41300. To use this critter to throttle UTDiag spewage, create an instance and set the interval(s), then call instance.RateCheck() every time you detect the error condition but only call UTDiag() when RateCheck() returns true. A static instance at/near the point of use works well. A typical usage scenario is often something like this: while (!Stopped()) { sleep(1); int statusBits = PollHardware(); if (statusBits != 0) { static TSC::RateLimiter throttle(60, 900, 7200, 86400); if (throttle.RateCheck()) { UTDiag("Franistan failure, status %#x", statusBits); // could do other things here too. } } } RateCheck() will internally manage advancement to the next-longer interval based on how long it has been since the prior actions. The RateCheck() function is fairly lightweight and can be called often (it just gets the current time and does a bit of adding and subtracting). If no call to RateCheck() is made for longer than the currently-active interval, the next call automatically resets the internal state back to the shortest interval. Say what? Well, let's say the hardware problem is ongoing and you've been calling RateCheck() once per second for a while and now it's only returning true once every 15 minutes. Magically, the hardware problem goes away and you don't call RateCheck() for a couple hours. Then the problem comes back so you call RateCheck() again and it notices that the time elapsed since the last call is longer than last active interval (15 minutes), so this isn't really a continuation of the previous situation, it's a whole new situation that starts over with the smallest interval and decays again from there over time. If you set multiple intervals, they should increase in value; if any given interval is shorter than the one before it, strange things are likely to happen. A zero ends the list (the zeroes are provided by the default args in the functions). If the first interval is zero, RateCheck() will always return false. You can force the internal state back to the shortest interval at any time by calling Reset(). After a reset, the next call to RateCheck() will return true, (unless the shortest interval is zero). The ctor calls Reset() internally, so the first call ever made to RateCheck() always returns true. -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 15:50:57 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC674B3C for ; Thu, 29 Nov 2012 15:50:57 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 388B88FC13 for ; Thu, 29 Nov 2012 15:50:56 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so11823243lbb.13 for ; Thu, 29 Nov 2012 07:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IiN0eGPG5rLQhOVkdSTDsgYdVfueNPV7BJcs5giANoo=; b=fGt0gLzFdYAmDmf6tDZny98RAQLlOlS+OCEEqTh/9Fot045y/DZKepSTIa1sU9ni9S 8A8EEJSaHR1RH4UGcdk1HgfYgS6hhdPYmUpcq3thS1OXUr+yC0UFwoJrgjhbDXRnfj8T VQ5hjkYAzL/Crs4K88Ib/omZXFHYt7oWUXNU4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=IiN0eGPG5rLQhOVkdSTDsgYdVfueNPV7BJcs5giANoo=; b=GkhZ+O11XzeBtVuSjvxO+ThEJPqrGbMA5JVmfObong3af5kLH4JxgLy/ED5QF/cRdv TtDiSMJgFL2o0o0JOYA8datvdPW9fEdQos9Ji+huaYnmPWF4T5XUiGslbl24E0CmXOBZ P1S55lHPSYfzJ/ntTrQizz7W3zY8tjy5CWZEvQxpSnK8Bz7iYiIqLFVGWusMRWVHQPAG kFF1ndYskzYX66zKMKlDO9ZEFc5YiEVoBFSyq/y0W9xmdqsv41YNUlCRPXfjMqn9leLk vdWzq4VdJWLnv/g2kU5ovoa5al6Y1o8I9y1lo0gLAun45r4Rpk0iETj/Of9JmbtmHpce 9bCQ== Received: by 10.112.38.103 with SMTP id f7mr6487468lbk.120.1354204255858; Thu, 29 Nov 2012 07:50:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.154.168 with HTTP; Thu, 29 Nov 2012 07:50:25 -0800 (PST) In-Reply-To: <20121129113503.GD3013@kib.kiev.ua> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129113503.GD3013@kib.kiev.ua> From: Eitan Adler Date: Thu, 29 Nov 2012 10:50:25 -0500 Message-ID: Subject: Re: Print a (rate-limited) warning when UMA zone is full. To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnC6tK4PCoczpoAtL1pa3NIetYlUMndSQ4xfeYKeLFPUnkvzLTZdTV6o8Q+pUy4ydGgGGWZ Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 15:50:57 -0000 On 29 November 2012 06:35, Konstantin Belousov wrote: >> This patch allows to configure advice for the use and give him some >> details in a very easy way. The warning printed on the console is >> rate-limited to one per second. > I cannot comment on the addition of the fields to struct uma_zone. > But please, can you drop the silly 'see tuning(7)' bytes ? Better, Keep them and fix tuning(7). -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 16:59:40 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84F3E842; Thu, 29 Nov 2012 16:59:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id E62EB8FC08; Thu, 29 Nov 2012 16:59:39 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qATGxcmO020899; Thu, 29 Nov 2012 20:59:38 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qATGxcAD020898; Thu, 29 Nov 2012 20:59:38 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 29 Nov 2012 20:59:38 +0400 From: Gleb Smirnoff To: Pawel Jakub Dawidek Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121129165938.GO14202@FreeBSD.org> References: <20121129090147.GB1370@garage.freebsd.pl> <20121129103752.GD1370@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20121129103752.GD1370@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Robert Watson , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:59:40 -0000 On Thu, Nov 29, 2012 at 11:37:52AM +0100, Pawel Jakub Dawidek wrote: P> I'm happy with using log(9), but currently when log(9) is used, the P> message is not printed on the console, it only ends up in the system P> log. printf(9) on the other hand is printed on the console and is P> appended to the system logs. P> P> The only case where log(9) will actually log to the console, AFAIR, is P> when syslogd is not working. ... or when syslogd is configured to log to console :) Extensive use of kernel printfs kills boxes that run serial consoles. I'd prefer to see all logging in kernel done via log(9) and default syslogd.conf configured to write kern.* to console. Those people, who run serial consoles can remove this from their syslogd.conf. -- Totus tuus, Glebius. From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 22:34:55 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74054B78 for ; Thu, 29 Nov 2012 22:34:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DC2B28FC13 for ; Thu, 29 Nov 2012 22:34:54 +0000 (UTC) Message-ID: <50B7E2D3.6070206@FreeBSD.org> Date: Thu, 29 Nov 2012 17:33:55 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Subject: [RFC] Remove i386 from bsd.cpu.mk X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------030904080501030108020701" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:34:55 -0000 This is a multi-part message in MIME format. --------------030904080501030108020701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to remove i386 from bsd.cpu.mk on head. Please see the attachment. It is also available from here: http://people.freebsd.org/~jkim/cpu-i386.diff Any objection? Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQt+LTAAoJECXpabHZMqHOXz4H/1R+8y8x+au79mkYVixCN9Yz jO0rw3EbcEGZSs61GbRKfSUdvbmcwHcXl3vnRyADRBESKGntTMFVTE3vwwbwCszG uARreZ5SORY7fKkFn+3wHmZGe19x4Ln9ouZMXVRXZX8hO8V1zM59uPXKwlbGTDbl y4Oq2m/vTmLMSpVPvhArRaHFKa8mGAhhf0J/o7oaknUZkNE2tiTm+bgnFjpSYbaS ozN+20Utrt2jSJqfNLWjjksLqqQDSmNvGSK4YEFBNWxqkCjmBz4VPbx+urmxv9qM eIkHM0T8JWoV01lO+weyhFGn4BMgvPJkGGmtuZarTaiQbnkg5TmdQ8fnk8XdwIw= =Tb0N -----END PGP SIGNATURE----- --------------030904080501030108020701 Content-Type: text/plain; charset=UTF-8; name="cpu-i386.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cpu-i386.diff" SW5kZXg6IHNoYXJlL2V4YW1wbGVzL2V0Yy9tYWtlLmNvbmYKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c2hhcmUvZXhhbXBsZXMvZXRjL21ha2UuY29uZgkocmV2aXNpb24gMjQzNjgzKQorKysgc2hh cmUvZXhhbXBsZXMvZXRjL21ha2UuY29uZgkod29ya2luZyBjb3B5KQpAQCAtMzUsNyArMzUs NyBAQAogIwkJCWF0aGxvbi10YmlyZCwgYXRobG9uLCBrNywgZ2VvZGUsIGs2LTMsIGs2LTIs IGs2LCBrNQogIyAgICAgICAoSW50ZWwgQ1BVcykJY29yZTIsIGNvcmUsIG5vY29uYSwgcGVu dGl1bTRtLCBwZW50aXVtNCwgcHJlc2NvdHQsCiAjCQkJcGVudGl1bTNtLCBwZW50aXVtMywg cGVudGl1bS1tLCBwZW50aXVtMiwKLSMJCQlwZW50aXVtcHJvLCBwZW50aXVtLW1teCwgcGVu dGl1bSwgaTQ4NiwgaTM4NgorIwkJCXBlbnRpdW1wcm8sIHBlbnRpdW0tbW14LCBwZW50aXVt LCBpNDg2CiAjICAgICAgIChWSUEgQ1BVcykJYzcsIGMzLTIsIGMzCiAjICAgQU1ENjQgYXJj aGl0ZWN0dXJlOglvcHRlcm9uLXNzZTMsIGF0aGxvbjY0LXNzZTMsIGs4LXNzZTMsIG9wdGVy b24sCiAjCQkJYXRobG9uNjQsIGs4LCBjb3JlMiwgbm9jb25hLCBwcmVzY290dApJbmRleDog c2hhcmUvbWsvYnNkLmNwdS5tawo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tay9ic2QuY3B1 Lm1rCShyZXZpc2lvbiAyNDM2ODMpCisrKyBzaGFyZS9tay9ic2QuY3B1Lm1rCSh3b3JraW5n IGNvcHkpCkBAIC0xNDUsNTkgKzE0NSw1NCBAQCBfQ1BVQ0ZMQUdTID0gLW1jcHU9dWx0cmFz cGFyYzMKIC4gaWYgJHtNQUNISU5FX0NQVUFSQ0h9ID09ICJpMzg2IgogLiAgaWYgJHtDUFVU WVBFfSA9PSAiYmR2ZXIxIiB8fCAke0NQVVRZUEV9ID09ICJiZHZlcjIiCiBNQUNISU5FX0NQ VSA9IHhvcCBhdnggc3NlNDIgc3NlNDEgc3NzZTMgc3NlNGEgc3NlMyBzc2UyIHNzZSBtbXgg azYgazUgaTU4NgotTUFDSElORV9DUFUgKz0gaTQ4NiBpMzg2CiAuICBlbGlmICR7Q1BVVFlQ RX0gPT0gImJ0dmVyMSIKLU1BQ0hJTkVfQ1BVID0gc3NzZTMgc3NlNGEgc3NlMyBzc2UyIHNz ZSBtbXggazYgazUgaTU4NiBpNDg2IGkzODYKK01BQ0hJTkVfQ1BVID0gc3NzZTMgc3NlNGEg c3NlMyBzc2UyIHNzZSBtbXggazYgazUgaTU4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJh bWRmYW0xMCIKIE1BQ0hJTkVfQ1BVID0gYXRobG9uLXhwIGF0aGxvbiBrNyAzZG5vdyBzc2U0 YSBzc2UzIHNzZTIgc3NlIG1teCBrNiBrNSBpNTg2Ci1NQUNISU5FX0NQVSArPSBpNDg2IGkz ODYKIC4gIGVsaWYgJHtDUFVUWVBFfSA9PSAib3B0ZXJvbi1zc2UzIiB8fCAke0NQVVRZUEV9 ID09ICJhdGhsb242NC1zc2UzIgotTUFDSElORV9DUFUgPSBhdGhsb24teHAgYXRobG9uIGs3 IDNkbm93IHNzZTMgc3NlMiBzc2UgbW14IGs2IGs1IGk1ODYgaTQ4NiBpMzg2CitNQUNISU5F X0NQVSA9IGF0aGxvbi14cCBhdGhsb24gazcgM2Rub3cgc3NlMyBzc2UyIHNzZSBtbXggazYg azUgaTU4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJvcHRlcm9uIiB8fCAke0NQVVRZUEV9 ID09ICJhdGhsb242NCIKLU1BQ0hJTkVfQ1BVID0gYXRobG9uLXhwIGF0aGxvbiBrNyAzZG5v dyBzc2UyIHNzZSBtbXggazYgazUgaTU4NiBpNDg2IGkzODYKK01BQ0hJTkVfQ1BVID0gYXRo bG9uLXhwIGF0aGxvbiBrNyAzZG5vdyBzc2UyIHNzZSBtbXggazYgazUgaTU4NgogLiAgZWxp ZiAke0NQVVRZUEV9ID09ICJhdGhsb24tbXAiIHx8ICR7Q1BVVFlQRX0gPT0gImF0aGxvbi14 cCIgfHwgXAogICAgICR7Q1BVVFlQRX0gPT0gImF0aGxvbi00IgotTUFDSElORV9DUFUgPSBh dGhsb24teHAgYXRobG9uIGs3IDNkbm93IHNzZSBtbXggazYgazUgaTU4NiBpNDg2IGkzODYK K01BQ0hJTkVfQ1BVID0gYXRobG9uLXhwIGF0aGxvbiBrNyAzZG5vdyBzc2UgbW14IGs2IGs1 IGk1ODYKIC4gIGVsaWYgJHtDUFVUWVBFfSA9PSAiYXRobG9uIiB8fCAke0NQVVRZUEV9ID09 ICJhdGhsb24tdGJpcmQiCi1NQUNISU5FX0NQVSA9IGF0aGxvbiBrNyAzZG5vdyBtbXggazYg azUgaTU4NiBpNDg2IGkzODYKK01BQ0hJTkVfQ1BVID0gYXRobG9uIGs3IDNkbm93IG1teCBr NiBrNSBpNTg2CiAuICBlbGlmICR7Q1BVVFlQRX0gPT0gIms2LTMiIHx8ICR7Q1BVVFlQRX0g PT0gIms2LTIiIHx8ICR7Q1BVVFlQRX0gPT0gImdlb2RlIgotTUFDSElORV9DUFUgPSAzZG5v dyBtbXggazYgazUgaTU4NiBpNDg2IGkzODYKK01BQ0hJTkVfQ1BVID0gM2Rub3cgbW14IGs2 IGs1IGk1ODYKIC4gIGVsaWYgJHtDUFVUWVBFfSA9PSAiazYiCi1NQUNISU5FX0NQVSA9IG1t eCBrNiBrNSBpNTg2IGk0ODYgaTM4NgorTUFDSElORV9DUFUgPSBtbXggazYgazUgaTU4Ngog LiAgZWxpZiAke0NQVVRZUEV9ID09ICJrNSIKLU1BQ0hJTkVfQ1BVID0gazUgaTU4NiBpNDg2 IGkzODYKK01BQ0hJTkVfQ1BVID0gazUgaTU4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJj MyIKLU1BQ0hJTkVfQ1BVID0gM2Rub3cgbW14IGk1ODYgaTQ4NiBpMzg2CitNQUNISU5FX0NQ VSA9IDNkbm93IG1teCBpNTg2CiAuICBlbGlmICR7Q1BVVFlQRX0gPT0gImMzLTIiCi1NQUNI SU5FX0NQVSA9IHNzZSBtbXggaTU4NiBpNDg2IGkzODYKK01BQ0hJTkVfQ1BVID0gc3NlIG1t eCBpNTg2CiAuICBlbGlmICR7Q1BVVFlQRX0gPT0gImM3IgotTUFDSElORV9DUFUgPSBzc2Uz IHNzZTIgc3NlIGk2ODYgbW14IGk1ODYgaTQ4NiBpMzg2CitNQUNISU5FX0NQVSA9IHNzZTMg c3NlMiBzc2UgaTY4NiBtbXggaTU4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJjb3JlaTct YXZ4IiB8fCAke0NQVVRZUEV9ID09ICJjb3JlLWF2eC1pIgotTUFDSElORV9DUFUgPSBhdngg c3NlNDIgc3NlNDEgc3NzZTMgc3NlMyBzc2UyIHNzZSBpNjg2IG1teCBpNTg2IGk0ODYgaTM4 NgorTUFDSElORV9DUFUgPSBhdnggc3NlNDIgc3NlNDEgc3NzZTMgc3NlMyBzc2UyIHNzZSBp Njg2IG1teCBpNTg2CiAuICBlbGlmICR7Q1BVVFlQRX0gPT0gImNvcmVpNyIKLU1BQ0hJTkVf Q1BVID0gc3NlNDIgc3NlNDEgc3NzZTMgc3NlMyBzc2UyIHNzZSBpNjg2IG1teCBpNTg2IGk0 ODYgaTM4NgorTUFDSElORV9DUFUgPSBzc2U0MiBzc2U0MSBzc3NlMyBzc2UzIHNzZTIgc3Nl IGk2ODYgbW14IGk1ODYKIC4gIGVsaWYgJHtDUFVUWVBFfSA9PSAiY29yZTIiCi1NQUNISU5F X0NQVSA9IHNzc2UzIHNzZTMgc3NlMiBzc2UgaTY4NiBtbXggaTU4NiBpNDg2IGkzODYKK01B Q0hJTkVfQ1BVID0gc3NzZTMgc3NlMyBzc2UyIHNzZSBpNjg2IG1teCBpNTg2CiAuICBlbGlm ICR7Q1BVVFlQRX0gPT0gInByZXNjb3R0IgotTUFDSElORV9DUFUgPSBzc2UzIHNzZTIgc3Nl IGk2ODYgbW14IGk1ODYgaTQ4NiBpMzg2CitNQUNISU5FX0NQVSA9IHNzZTMgc3NlMiBzc2Ug aTY4NiBtbXggaTU4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJwZW50aXVtNCIgfHwgJHtD UFVUWVBFfSA9PSAicGVudGl1bTRtIiB8fCBcCiAgICAgJHtDUFVUWVBFfSA9PSAicGVudGl1 bS1tIgotTUFDSElORV9DUFUgPSBzc2UyIHNzZSBpNjg2IG1teCBpNTg2IGk0ODYgaTM4Ngor TUFDSElORV9DUFUgPSBzc2UyIHNzZSBpNjg2IG1teCBpNTg2CiAuICBlbGlmICR7Q1BVVFlQ RX0gPT0gInBlbnRpdW0zIiB8fCAke0NQVVRZUEV9ID09ICJwZW50aXVtM20iCi1NQUNISU5F X0NQVSA9IHNzZSBpNjg2IG1teCBpNTg2IGk0ODYgaTM4NgorTUFDSElORV9DUFUgPSBzc2Ug aTY4NiBtbXggaTU4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJwZW50aXVtMiIKLU1BQ0hJ TkVfQ1BVID0gaTY4NiBtbXggaTU4NiBpNDg2IGkzODYKK01BQ0hJTkVfQ1BVID0gaTY4NiBt bXggaTU4NgogLiAgZWxpZiAke0NQVVRZUEV9ID09ICJwZW50aXVtcHJvIgotTUFDSElORV9D UFUgPSBpNjg2IGk1ODYgaTQ4NiBpMzg2CitNQUNISU5FX0NQVSA9IGk2ODYgaTU4NgogLiAg ZWxpZiAke0NQVVRZUEV9ID09ICJwZW50aXVtLW1teCIKLU1BQ0hJTkVfQ1BVID0gbW14IGk1 ODYgaTQ4NiBpMzg2CitNQUNISU5FX0NQVSA9IG1teCBpNTg2CiAuICBlbGlmICR7Q1BVVFlQ RX0gPT0gInBlbnRpdW0iCi1NQUNISU5FX0NQVSA9IGk1ODYgaTQ4NiBpMzg2Ci0uICBlbGlm ICR7Q1BVVFlQRX0gPT0gImk0ODYiCi1NQUNISU5FX0NQVSA9IGk0ODYgaTM4NgotLiAgZWxp ZiAke0NQVVRZUEV9ID09ICJpMzg2IgotTUFDSElORV9DUFUgPSBpMzg2CitNQUNISU5FX0NQ VSA9IGk1ODYKIC4gIGVuZGlmCitNQUNISU5FX0NQVSArPSBpNDg2CiAuIGVsaWYgJHtNQUNI SU5FX0NQVUFSQ0h9ID09ICJhbWQ2NCIKIC4gIGlmICR7Q1BVVFlQRX0gPT0gImJkdmVyMSIg fHwgJHtDUFVUWVBFfSA9PSAiYmR2ZXIyIgogTUFDSElORV9DUFUgPSB4b3AgYXZ4IHNzZTQy IHNzZTQxIHNzc2UzIHNzZTRhIHNzZTMKSW5kZXg6IHVzci5iaW4vbWFrZS9tYWluLmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gdXNyLmJpbi9tYWtlL21haW4uYwkocmV2aXNpb24gMjQzNjgzKQor KysgdXNyLmJpbi9tYWtlL21haW4uYwkod29ya2luZyBjb3B5KQpAQCAtOTc2LDcgKzk3Niw3 IEBAIG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogCSAqLwogCWlmICgobWFjaGluZV9j cHUgPSBnZXRlbnYoIk1BQ0hJTkVfQ1BVIikpID09IE5VTEwpIHsKIAkJaWYgKCFzdHJjbXAo bWFjaGluZV9hcmNoLCAiaTM4NiIpKQotCQkJbWFjaGluZV9jcHUgPSAiaTM4NiI7CisJCQlt YWNoaW5lX2NwdSA9ICJpNDg2IjsKIAkJZWxzZQogCQkJbWFjaGluZV9jcHUgPSAidW5rbm93 biI7CiAJfQo= --------------030904080501030108020701-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 22:41:47 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A798E7A for ; Thu, 29 Nov 2012 22:41:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABD78FC12 for ; Thu, 29 Nov 2012 22:41:46 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so14048648qcs.13 for ; Thu, 29 Nov 2012 14:41:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/OaI+SBF4lBSEFCW1OTP8Qy4tPVuiqL13vm0oQTifyI=; b=L/J42S+t3HFkUPI1sKaOOsETavnFEfi02DlYy35WeCNSwQykRJe1rNgeE5eIpImODq 61JxaIlSPX13eXhbdgZ3t8Tm+DJjYdGxGoL8I30BH8feX8mn6msS0IPgIX6ePFjGIksn jPQ+pGOA+MeU8bkF7NLRrGjVJx9v7bqZ/CmOMIhZQtbtDq+g7UywQHgzF1i6wKjDshA9 0nqs3y5T5FToupeH8u1UcPWQFfq0pY9l3NMehs5ZGbxdLCGUmaZgkEzFpovR5Qu+UnKl 4jvxYK6F4cnRbgsCZYRyTikfQQsvcB7eNJndgV2fX4yCKoE64J9SiUu69T9DQrvYCa7N Qm/Q== Received: by 10.224.201.71 with SMTP id ez7mr22060qab.44.1354228906406; Thu, 29 Nov 2012 14:41:46 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id z9sm1425591qeg.9.2012.11.29.14.41.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 14:41:44 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] Remove i386 from bsd.cpu.mk Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50B7E2D3.6070206@FreeBSD.org> Date: Thu, 29 Nov 2012 15:41:40 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <50B7E2D3.6070206@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlLOq42RUOXSWlGI2KGWyTj1LCybW0cHoRma9DG5/K8OsRnI8SQw0QZOgVpPhpJYwk4+Z0f Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:41:47 -0000 This looks good to me. Warner On Nov 29, 2012, at 3:33 PM, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd like to remove i386 from bsd.cpu.mk on head. Please see the > attachment. It is also available from here: > > http://people.freebsd.org/~jkim/cpu-i386.diff > > Any objection? > > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQt+LTAAoJECXpabHZMqHOXz4H/1R+8y8x+au79mkYVixCN9Yz > jO0rw3EbcEGZSs61GbRKfSUdvbmcwHcXl3vnRyADRBESKGntTMFVTE3vwwbwCszG > uARreZ5SORY7fKkFn+3wHmZGe19x4Ln9ouZMXVRXZX8hO8V1zM59uPXKwlbGTDbl > y4Oq2m/vTmLMSpVPvhArRaHFKa8mGAhhf0J/o7oaknUZkNE2tiTm+bgnFjpSYbaS > ozN+20Utrt2jSJqfNLWjjksLqqQDSmNvGSK4YEFBNWxqkCjmBz4VPbx+urmxv9qM > eIkHM0T8JWoV01lO+weyhFGn4BMgvPJkGGmtuZarTaiQbnkg5TmdQ8fnk8XdwIw= > =Tb0N > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 22:42:00 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C3B3F17; Thu, 29 Nov 2012 22:42:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id E16AB8FC13; Thu, 29 Nov 2012 22:41:59 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so19378922oag.13 for ; Thu, 29 Nov 2012 14:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6rhEwsUS3pD/11dR5UZ3MTGH+eHjPJG1xkVk6oEE16o=; b=ERC+8+Yrwua0iUa8n5E92GU+bT9YJeN9NPHKo8oJe+vawGQ4kuKDYu7LIIh8nW8QoK zcHotXuaccJbFTqOQYrVFch2rzYYPMn2ErdIIVd9q6oNUrLzzWDgrNZ/ENTUCPDtD73z RHTXtIa3SXoiUU5+Nzu6GTOz4eynrvLYm1sMWMI/mmS0vpGsQ4A3WoOzmZivox2YqHhd M5/FZDuNwqhdxgtwJ6gpQ4Z90AgcJeUyOs+nPbu4lBmYirilLuQbkpTJqYA2DfUqNfKO FpGJ3ORANOeH0PxGdgYaMMXplY4af5d+/iqk+Jl97EkYVP9w2k/aiNtTiW+lup6ue3Ts IXhA== MIME-Version: 1.0 Received: by 10.60.13.198 with SMTP id j6mr3067210oec.51.1354228919323; Thu, 29 Nov 2012 14:41:59 -0800 (PST) Received: by 10.76.143.33 with HTTP; Thu, 29 Nov 2012 14:41:59 -0800 (PST) In-Reply-To: <50B7E2D3.6070206@FreeBSD.org> References: <50B7E2D3.6070206@FreeBSD.org> Date: Thu, 29 Nov 2012 14:41:59 -0800 Message-ID: Subject: Re: [RFC] Remove i386 from bsd.cpu.mk From: Garrett Cooper To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:42:00 -0000 On Thu, Nov 29, 2012 at 2:33 PM, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd like to remove i386 from bsd.cpu.mk on head. Please see the > attachment. It is also available from here: > > http://people.freebsd.org/~jkim/cpu-i386.diff > > Any objection? None from me (I don't run Geodes, etc though :)...). Just wanted to add that you're removing i486 as well. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 22:46:29 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CE5A6B; Thu, 29 Nov 2012 22:46:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19FDB8FC12; Thu, 29 Nov 2012 22:46:28 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so19383604oag.13 for ; Thu, 29 Nov 2012 14:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UUChkyzIZINCvTQHj3fZ47+2dLjzlO13DaQYTeh08kU=; b=Ii+OP3+XcucCWbz4v2F+MLN8zY+Zi9G/HMwHfTda0YBrDr2m7H4TgnikWozG3v9WHI Bmc1iDfyRi3pILLCgSGZQ8/VzRV6zCKjwR/Etjtj8UZbWMnYNwtmIlYZXaX+hmVmC3EA gl4ekFB13YSIi2jMbyeSJ8au2llHZwjRFilGcNrrS5Lb43c6a4Tfy6C9cwbAzuoo7WFh s9+EI/slPh/MYhleg+BE6rhlxNuzKUt6OG9W2OmCGrwE0IWQkPoNEtfn3NJU3kYIeOYP o+sJgqtaypNsq82PHSGksKXAIVINYrRTfdKcKZDlyUuPRmBzTV0ZeNdAb7upFhKGRCY4 PtSA== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr9376151obc.83.1354229188300; Thu, 29 Nov 2012 14:46:28 -0800 (PST) Received: by 10.76.143.33 with HTTP; Thu, 29 Nov 2012 14:46:28 -0800 (PST) In-Reply-To: References: <50B7E2D3.6070206@FreeBSD.org> Date: Thu, 29 Nov 2012 14:46:28 -0800 Message-ID: Subject: Re: [RFC] Remove i386 from bsd.cpu.mk From: Garrett Cooper To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:46:29 -0000 On Thu, Nov 29, 2012 at 2:41 PM, Garrett Cooper wrote: > On Thu, Nov 29, 2012 at 2:33 PM, Jung-uk Kim wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I'd like to remove i386 from bsd.cpu.mk on head. Please see the >> attachment. It is also available from here: >> >> http://people.freebsd.org/~jkim/cpu-i386.diff >> >> Any objection? > > None from me (I don't run Geodes, etc though :)...). Just wanted to > add that you're removing i486 as well. Also, because you're removing i486 from bsd.cpu.mk, does it make sense for make to default to it and not i586? Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 22:47:42 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 272331C9 for ; Thu, 29 Nov 2012 22:47:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 0621B8FC15 for ; Thu, 29 Nov 2012 22:47:42 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 3E8BBCE2E; Thu, 29 Nov 2012 14:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1354229261; bh=LwAN59pJnMbMtU5osifumhNJk0GRHWyltZTGxVjfNIw=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=xJCwzGll7BLy0TSQHg/p3RHoQtw5F1gz7tMHqlkT7Akqf70ZgZLP3sG6OeGbdEf6N vsw2Eof9ydbTZd+5b6r4u8NZfZRs0aJakPK0+CAhkUCSzbA060EKM6Zo7hyV9xg9+I wbHQelBjrKixYJubuGCbuVe3oz3UUSzfVxgf+PvE= Message-ID: <50B7E608.5020405@delphij.net> Date: Thu, 29 Nov 2012 14:47:36 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: [RFC] Remove i386 from bsd.cpu.mk References: <50B7E2D3.6070206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:47:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/29/12 14:41, Garrett Cooper wrote: > On Thu, Nov 29, 2012 at 2:33 PM, Jung-uk Kim > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> I'd like to remove i386 from bsd.cpu.mk on head. Please see the >> attachment. It is also available from here: >> >> http://people.freebsd.org/~jkim/cpu-i386.diff >> >> Any objection? > > None from me (I don't run Geodes, etc though :)...). Just wanted > to add that you're removing i486 as well. He isn't, i486 have became a common value in the .mk change (last 3 lines) when the architecture is i386. I believe the proposed change is good to go. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJQt+YIAAoJEG80Jeu8UPuzFegIAIPrUxyRVG8QlcmkRwfhAMWb PtXyLnvl3ARfxkDmg7n4cvxMgT7TQm0s/TM+G1c0esSNfJX3XosmU8qYZTEs8Q4o 8NbX4ydqLeNaMLNF8kc7ARKRrZYO5WkEDvxHiYen1jENPd9Tzy1CjvxIsnpnvmfX MXEY8VEusVadPdcQ1pNds5LxqNBQBrq3RTaBwtICozLKClNB91AfxEGQYG4DYHL5 dOwpRdYU24Arcx4tR4hUsDsv1QLJhjygWH0iKRSAfpH6WQh12cjOdGW4hbMpwncH q1JLqxis7QL+UbqBdH6edIP+Z9ZoDhHXYXzfbJeJXfwnnxT5S30ql19uaEKaZ80= =8dfy -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 22:49:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 944B128C for ; Thu, 29 Nov 2012 22:49:07 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3E28FC0C; Thu, 29 Nov 2012 22:49:07 +0000 (UTC) Message-ID: <50B7E628.9050408@FreeBSD.org> Date: Thu, 29 Nov 2012 17:48:08 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: [RFC] Remove i386 from bsd.cpu.mk References: <50B7E2D3.6070206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 22:49:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-11-29 17:41:59 -0500, Garrett Cooper wrote: > On Thu, Nov 29, 2012 at 2:33 PM, Jung-uk Kim > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> I'd like to remove i386 from bsd.cpu.mk on head. Please see the >> attachment. It is also available from here: >> >> http://people.freebsd.org/~jkim/cpu-i386.diff >> >> Any objection? > > None from me (I don't run Geodes, etc though :)...). Just wanted > to add that you're removing i486 as well. No, I am not. It is always added at the end. MACHINE_CPU += i486 :-) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQt+YoAAoJECXpabHZMqHO2W4H+gP63tZSMtcBn/RBjgH1lGVs oyZ/CK9JJr5vIBajkv15hYphsM3dW/RrFiCcZ+yViBTqgOuTvoAeTOz6LFNynWmc AHBwq2ab/84Az1hLYgJmsYnDuYTiC0jsNTaMW2C22kEv4JIG1GZcupjbBRIbCgu2 EdBrhPDEGJIx904xRnpTkPwa0NZCA3sFMH7+KCWMiJOPLGJrcPSEMNy6fiIBK60p tW1TkQGfqOUtyCBo0TO0XvFgBIMDTlOkaqSkfQ7vpep4Zc9tSAAwonKoSxFrNy6o fDhDn4XN/2l+GkB8cgqQoqCjPhi/KjGAdcOR6RQKsqULYhkrrUV2DUxFpghns8o= =k5fQ -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 29 23:00:04 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 042B6473; Thu, 29 Nov 2012 23:00:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7CDA08FC13; Thu, 29 Nov 2012 23:00:02 +0000 (UTC) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qATMrpkj011780; Fri, 30 Nov 2012 09:53:51 +1100 Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qATMrfTM002277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2012 09:53:43 +1100 Date: Fri, 30 Nov 2012 09:53:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Robert Watson Subject: Re: Print a (rate-limited) warning when UMA zone is full. In-Reply-To: Message-ID: <20121130084954.Q1018@besplex.bde.org> References: <20121129090147.GB1370@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=CJhyxmXD c=1 sm=1 a=TqqRvdq6UwwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=WuX6JDzwDc4A:10 a=6I5d2MoRAAAA:8 a=E09R5ns7edqif91MdbwA:9 a=CjuIK1q_8ugA:10 a=xKUfbGQrvFFeCKXi:21 a=TAK9j_RUqiU3tQD2:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 23:00:04 -0000 On Thu, 29 Nov 2012, Robert Watson wrote: > On Thu, 29 Nov 2012, Pawel Jakub Dawidek wrote: > >> I'd like to propose the following patch: >> >> http://people.freebsd.org/~pjd/patches/uma_warning.patch Please include small (< 10000 line) patches in mail. They would have to be included in replies to review them. >> When UMA zone is created, one can add configure a warning that should be >> printed when UMA zone is full by calling: >> >> uma_zone_set_warning(socket_zone, >> "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); Please don't clone messages of this form. It has bad grammar, bad style and a garbage pointer. Many of these were cloned from previous messages of this form. Bad grammar: 1. Redundant "limit". kern.ipc.maxsockets is already a limit. 2. Wrong object. The thing not being exceeded is the number of sockets, not the limit on the number of sockets. 3. Wrong verb. It is impossible to exceed an enforcible, enforced limit This seems hard to fix without making the message too verbose. A full description would say something to the effect that that the limit would be exeeded if exceeding it were possible and permitted. Or some conventional wording for this situation could be used. The above has conventional wording, but has too many errors for me. 4. comma splice Bad style: 5. pleading 6. termination with a ".'. Error messages are conventionally not terminated 7. general verboseness, with the help of (1), (5) and (7). > Just to follow up on some out-of-band communication -- this is a good idea, > but there was some concern about printf() under mutexes. I'm not actually > that concerned about that case (we do it quite a lot for warnings and kernel > debugging), but it might be useful to consider using log() instead, so that > it ends up in the system log as well as on the console. printf() works in the "any" context so it is less restricted than log(). But it is less controllable, and spams the console. > Finally, we should make sure that in all instances where we point at > tuning(7), it has something useful to say about the topic :-). This is the garbage pointer: 8. Pointer to nonexistent or too-generic info in tuning(7). Since you didn't include the patch, I couldn't see if it provided the info, but other replies in this thread complained about this too and said that it didn't. When messages of this form were originally implemented, many of them pointed to garbage. Now some of them are documented there. But I think this is a wrong place, except for generic info about how to change complicated interacting sysctls. Each sysctl should be described in a more specialized man page, and documenting sysctls in a general place like tuning gives duplication or inhibits the specialized documentation. Current messages of this form in freefall's kernel: % Consider tuning vm.kmem_size and vm.kmem_size_max Apparently part of an essay written in an error message. % kern.maxfiles limit exceeded by uid %i, please see tuning(7). Has all the above errors, plus %i instead of %d in the printf format (not just a style bug, but a type error. uid_t is not only a typedefed type that might differ from int; it does differ from int since it is unsigned. %i misprints valid uids that exceed INT_MAX. POSIX requires uids to be nonnegative integers, though IIRC it doesn't require uid_t to be unsigned or even integral in old versions. But in FreeBSD, uids can be anything representable by uid_t, so the printf format must match uid_t. tuning(7) actuall mentions this. % maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5). This describes the limit as "maxproc limit" instead of as kern.maxproc. This avoids bugs (1) and (2), but makes finding the info a little harder. It references another man page that provides very little relevant info. login.conf(5) has 1 line about maxproc and that line does nother except un-abbreviate it. This is better than tuning(7), which has no lines about maxproc or limits on it. % kern.ipc.maxpipekva exceeded; see tuning(7) This is missing bugs (1), (2), (4), (5) (6) and (7), because I complained strongly enough about it when it was committed. The original version was also missing ".ipc" in the sysctl name, so the pointer to tuning(7) was garbage in a different way. % Configure virtual memory overcommit behavior. See tuning(7) for details. This is the description for the vm.overcommit sysctl. It avoids errors (1)-(6) but not (7). Its fix for the comma splice is to use multiple sentences with a misformatted sentence break. With multiple sentences, the terminating '.' is arguably not a style bug. But verbose descriptions that need multiple sentences are. This is actually mentioned in tuning(7). References to man pages are especially unnecessary in sysctl descriptions and are mercifully absent for all the sysctls mentioned in rate-limited messages that mention tuning(7). It should go without saying that every sysctl description is expanded in the man page(s) about the sysctl, if the sysctl actually has a man page. Relevant man pages are most easily found using 'zgrep -irl /usr/share/man'. For that, it is useful to give the full sysctl name in all places and not paraphrase it like "maxproc limit". Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 07:30:49 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DABA3644; Fri, 30 Nov 2012 07:30:49 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 97D958FC08; Fri, 30 Nov 2012 07:30:48 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 269CDBEB; Fri, 30 Nov 2012 08:28:56 +0100 (CET) Date: Fri, 30 Nov 2012 08:32:08 +0100 From: Pawel Jakub Dawidek To: Bruce Evans Subject: Re: Print a (rate-limited) warning when UMA zone is full. Message-ID: <20121130073208.GA1409@garage.freebsd.pl> References: <20121129090147.GB1370@garage.freebsd.pl> <20121130084954.Q1018@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20121130084954.Q1018@besplex.bde.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Robert Watson , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 07:30:49 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 30, 2012 at 09:53:41AM +1100, Bruce Evans wrote: > >> When UMA zone is created, one can add configure a warning that should = be=20 > >> printed when UMA zone is full by calling: > >>=20 > >> uma_zone_set_warning(socket_zone, > >> "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); >=20 > Please don't clone messages of this form. It has bad grammar, bad > style and a garbage pointer. Many of these were cloned from previous > messages of this form. >=20 > Bad grammar: > 1. Redundant "limit". kern.ipc.maxsockets is already a limit. I don't think I can agree here. kern.ipc.maxsockets is not only a limit - it is a string, a sysctl, a tunable... being specific that we are talking about kern.ipc.maxsockets limit is a good thing, IMHO. > 2. Wrong object. The thing not being exceeded is the number of sockets, > not the limit on the number of sockets. > 3. Wrong verb. It is impossible to exceed an enforcible, enforced limit > This seems hard to fix without making the message too verbose. A full > description would say something to the effect that that the limit wou= ld > be exeeded if exceeding it were possible and permitted. Or some > conventional wording for this situation could be used. The above has > conventional wording, but has too many errors for me. I agree 'exceeded' is wrong word here, I copied the message from kern.maxfiles warning, but really the messages in the patch were just examples how the new function can be used. How about this: The kern.ipc.maxsockets limit has be reached. The message is short. It tells what to tune. It gives sysctl name, so hopefully sysctl description will tell more about this limit. I'm not a native English speaker, so I'm open to other suggestions of course. > 6. termination with a ".'. Error messages are conventionally not termina= ted We probably won't reach an agreement here. In my opinion every sentence should be terminated with a period. Also it is a warning not an error message. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlC4YPgACgkQForvXbEpPzRKHgCfTG+3HSRYhVqyrbfWBfjeeFPl RrkAn0Em9Y8QL41buqcrxtZ5o18r9ygo =v7LY -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 30 08:38:46 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A427E6B0; Fri, 30 Nov 2012 08:38:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 334FE8FC08; Fri, 30 Nov 2012 08:38:45 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAU8cZim003245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2012 19:38:38 +1100 Date: Fri, 30 Nov 2012 19:38:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pawel Jakub Dawidek Subject: Re: Print a (rate-limited) warning when UMA zone is full. In-Reply-To: <20121130073208.GA1409@garage.freebsd.pl> Message-ID: <20121130185557.I2742@besplex.bde.org> References: <20121129090147.GB1370@garage.freebsd.pl> <20121130084954.Q1018@besplex.bde.org> <20121130073208.GA1409@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zr21sKHG c=1 sm=1 a=TqqRvdq6UwwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=WuX6JDzwDc4A:10 a=JQ36l8qXi9v9E1mqdogA:9 a=CjuIK1q_8ugA:10 a=7SeEaO9UiTjU2N2W:21 a=ttdjKn6eXhUdmR15:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: Robert Watson , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 08:38:46 -0000 On Fri, 30 Nov 2012, Pawel Jakub Dawidek wrote: > On Fri, Nov 30, 2012 at 09:53:41AM +1100, Bruce Evans wrote: >>>> When UMA zone is created, one can add configure a warning that should be >>>> printed when UMA zone is full by calling: >>>> >>>> uma_zone_set_warning(socket_zone, >>>> "kern.ipc.maxsockets limit exceeded, please see tuning(7)."); >> >> Please don't clone messages of this form. It has bad grammar, bad >> style and a garbage pointer. Many of these were cloned from previous >> messages of this form. >> >> Bad grammar: >> 1. Redundant "limit". kern.ipc.maxsockets is already a limit. > > I don't think I can agree here. kern.ipc.maxsockets is not only a limit > - it is a string, a sysctl, a tunable... being specific that we are > talking about kern.ipc.maxsockets limit is a good thing, IMHO. There is nothing to disagree on -- this is a matter of fact. If the sysctl were named kern.ipc.limitsockets ("limit" instead of "max") or just "limit", then the redundancy would be even clearer and uglier. >> 2. Wrong object. The thing not being exceeded is the number of sockets, >> not the limit on the number of sockets. >> 3. Wrong verb. It is impossible to exceed an enforcible, enforced limit >> This seems hard to fix without making the message too verbose. A full >> description would say something to the effect that that the limit would >> be exeeded if exceeding it were possible and permitted. Or some >> conventional wording for this situation could be used. The above has >> conventional wording, but has too many errors for me. > > I agree 'exceeded' is wrong word here, I copied the message from > kern.maxfiles warning, but really the messages in the patch were just > examples how the new function can be used. > > How about this: > > The kern.ipc.maxsockets limit has be reached. > > The message is short. It tells what to tune. It gives sysctl name, so > hopefully sysctl description will tell more about this limit. I'm not a > native English speaker, so I'm open to other suggestions of course. "has be reached" should be "has been reached", which sounds too formal and verbose to me. It has a complicated tense, so it may be especially difficult for non-native English speakers. Further fixes to the kern.ipc.maxpipekva message (change "exceeded" to "reached" and remove the reference to tuning(7)) and copying them here gives: kern.ipc.maxsockets reached If you want to use "limit" and have perfect grammar, then correct use would be: The limit on the number of sockets (kern.ipc.maxsockets) [has been] reached. This is too verbose for me. >> 6. termination with a ".'. Error messages are conventionally not terminated > > We probably won't reach an agreement here. In my opinion every sentence > should be terminated with a period. Also it is a warning not an error > message. Again, there is nothing to disagree on. It is a fact that error messages and sysctl descriptions are conventionally not terminated with a "." in BSD. This at least saves space. For error messages, it avoids some technical problems. The perror(), err() and warn() APIs append a colon, a space, strerror(errno) (except for perror(NULL), and a newline. Any termination of the application's string by a "." would give the garbage punctuation ".:" after the colon is appended. These APIs never append a "." after strerror(errno). This is a major source of unterminated error messages. If you insist on the ".", then I will insist on perfect grammar (within space constraints), including when something adds a prefix or a suffix :-). Perfect grammar is difficult using the err() family, and terminating with a "." is impossible for err() and warn(). You would have to subvert the API and use errx() and warnx() with %s and strerror(errno) to get enough control over the output to just terminate it with a ".". Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Dec 1 14:48:36 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71E68291; Sat, 1 Dec 2012 14:48:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD758FC0C; Sat, 1 Dec 2012 14:48:36 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f19f:4a41:71ae:f9e6] (unknown [IPv6:2001:7b8:3a7:0:f19f:4a41:71ae:f9e6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B24AF5C37; Sat, 1 Dec 2012 15:48:34 +0100 (CET) Message-ID: <50BA18CB.2080001@FreeBSD.org> Date: Sat, 01 Dec 2012 15:48:43 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jung-uk Kim Subject: Re: [RFC] Remove i386 from bsd.cpu.mk References: <50B7E2D3.6070206@FreeBSD.org> In-Reply-To: <50B7E2D3.6070206@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 14:48:36 -0000 On 2012-11-29 23:33, Jung-uk Kim wrote: > I'd like to remove i386 from bsd.cpu.mk on head. Please see the > attachment. It is also available from here: > > http://people.freebsd.org/~jkim/cpu-i386.diff > > Any objection? No, please commit. Deorbit of i386 complete! ;)