From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 09:36:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DD0B44E; Sun, 9 Nov 2014 09:36:38 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30C8F2A6; Sun, 9 Nov 2014 09:36:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sA99aWQe042257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2014 11:36:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA99aWQe042257 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA99aWVq042256; Sun, 9 Nov 2014 11:36:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Nov 2014 11:36:32 +0200 From: Konstantin Belousov To: Shrikanth Kamath Subject: Re: DTrace: stack() does not print kernel module functions for i386 Message-ID: <20141109093632.GV53947@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, avg@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 09:36:38 -0000 On Sat, Nov 08, 2014 at 02:06:39PM -0800, Shrikanth Kamath wrote: > I verified this on a FreeBSD 10.0 STABLE, the stack() feature does not > appear to print functions from kernel modules. I believe there is a > glitch in libdtrace in the function "dt_module_update" > (cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c). > > The section header address computation which is currently being done > in the function dt_module_update for elf type ET_REL, a similar > computation needs to be done for the ET_DYN maybe. I lack background > on the elf types but for experiment sakes I changed the line > > @@ -948,7 +948,7 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_fil > #if defined(__FreeBSD__) > mapbase = (uintptr_t)k_stat->address; > gelf_getehdr(dmp->dm_elf, &ehdr); > - is_elf_obj = (ehdr.e_type == ET_REL); > + is_elf_obj = (ehdr.e_type == ET_REL) || (ehdr.e_type == ET_DYN); > if (is_elf_obj) { > dmp->dm_sec_offsets = > malloc(ehdr.e_shnum * sizeof(*dmp->dm_sec_offsets)); > > So from a previous run where I was running a dtrace one liner > %dtrace -n 'fbt:hwpmc:: { stack(); }' > The output without the above change shows a sample as > > 0 50825 pmc_find_process_descriptor:entry > 0xc3c35bf5 <-- Address > not matched to symbol > kernel`syscall+0x48b > kernel`0xc0fd2121 > > whereas with the above nit change to include ET_DYN for section offset > adjustment I get the complete stack trace as > > 0 50825 pmc_find_process_descriptor:entry > hwpmc.ko`pmc_hook_handler+0x6a5 <--address matched to symbol > kernel`syscall+0x48b > kernel`0xc0fd2121 > > I believe without the correct section offset adjustment the following > check in the function dtrace_lookup_by_addr fails to match the address > to the correct symbol > > if (addr - dmp->dm_text_va < dmp->dm_text_size || > addr - dmp->dm_data_va < dmp->dm_data_size || > addr - dmp->dm_bss_va < dmp->dm_bss_size) > > because dml->dm_text_va was not setup correctly in dt_module_update. > > Can somebody help clarify this? > > Reference: commit revision 210425. I have no idea about DTrace guts, but can add one note you might find useful. >From the backtace above I can conclude that your platform is i386. A difference between i386 and amd64 is that i386 modules are dso's (ET_DYN), while on amd64 modules are only linked to object files (ET_REL). The original author of the code probably tested on amd64. You may want to special case amd64 by #ifdef, and use ET_DYN on other arches. From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 16:19:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56E6420B for ; Sun, 9 Nov 2014 16:19:47 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDD34A24 for ; Sun, 9 Nov 2014 16:19:46 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id h11so8418902wiw.0 for ; Sun, 09 Nov 2014 08:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=y3aDpaE4WoDfP4oM4I0FibyyM/cGKmwgfe4Ua5IqAUg=; b=BEAN4QtgQz7r8OsfSdJlWdVsU+71+h8KERQateJlN7pG985WUQtk4noFDP0dflSFtC T9FtiLiT4fgrqyiGIBkvIIm0oSasFOFGoMkc12PX0STwb8AVrJKoeM30KIuVVUCuJIlp 01+K9ZZd0xKobhs8ahtQUJWHyEaR7k0l4YEL0DkIka844NU3H9h7onCcjYpmX8fJ19XW hRISzhmutSoQrKAL5DPpmGmfQ2sVUOVNffcoqEuR3WLfjCwaDbPUnEOX5XT7ziRa8H4H 9mTgvixow6IUvM/QY5JUwhM4GWdN4CwPOaA8fw4gyndLsg5KGNIq69V3fOsoiztB65nR lhDA== X-Received: by 10.194.78.82 with SMTP id z18mr33321312wjw.120.1415549984020; Sun, 09 Nov 2014 08:19:44 -0800 (PST) Received: from brick.home (adho154.neoplus.adsl.tpnet.pl. [79.184.170.154]) by mx.google.com with ESMTPSA id n4sm9902552wiz.17.2014.11.09.08.19.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Nov 2014 08:19:43 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 9 Nov 2014 17:19:41 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Hans Ottevanger Subject: Re: Fwd: Autofs: spurious (?) log messages and zombies from automountd Message-ID: <20141109161941.GA50201@brick.home> Mail-Followup-To: Hans Ottevanger , "freebsd-hackers@freebsd.org" References: <54226E4D.1040704@beastielabs.net> <54250A50.1000607@beastielabs.net> <20140926090053.GA10644@brick.home> <542540BB.80001@beastielabs.net> <542580F6.7030609@beastielabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <542580F6.7030609@beastielabs.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 16:19:47 -0000 On 0926T1706, Hans Ottevanger wrote: > On 09/26/14 12:32, Hans Ottevanger wrote: > > On 09/26/14 11:00, Edward Tomasz Napierała wrote: > >> On 0926T0840, Hans Ottevanger wrote: > > [...] > > > > > I planned to make a new CURRENT snapshot installation on another machine > > anyhow today. I will see what happens there. > > > > I just verified that with fresh installations of both 10.1-BETA2 and the > latest CURRENT snapshot (based on r271779) the same issue occurs. It should be fixed in CURRENT. From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 18:13:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26AFAD88 for ; Sun, 9 Nov 2014 18:13:23 +0000 (UTC) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D593C69D for ; Sun, 9 Nov 2014 18:13:22 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id le20so3318581vcb.32 for ; Sun, 09 Nov 2014 10:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=f6haVPwXdp3foODB+owkkGFxSZqIbZOW1N298Jh+GNc=; b=BhG5EMMo8ll19qClFFouuc67XgszhXjmH7fYumVNXx1hOd1A3DHuUcA5KX3KE+P+yr KlbwgKuZkXUAHum2T9lqp3f1xiBlSHGANBNHkLa+Ez3J8ahNtQmxRFiNEQWhDq3kwnKV ACiStkTKIYzFEa06IVI0NCPpPQ3g3qFXDmkk349Udag5ZGXZ3/NU3bXp2hoC4aO/RSBs 8k+WYnKqAFG3fRvWfOlP83kSdMxHn/m6cVQYIzjNLR4tNQzR4pYrgeUYuPZ5dMPFNShS 5R10XxTwXcV2Tu2s4mNeMkmHPWTu7v6/B7HiFtjMv2H6wJ4CONY+02fC6xTrf/HJF0bv uFfw== MIME-Version: 1.0 X-Received: by 10.221.36.73 with SMTP id sz9mr17441373vcb.17.1415556801782; Sun, 09 Nov 2014 10:13:21 -0800 (PST) Received: by 10.221.64.74 with HTTP; Sun, 9 Nov 2014 10:13:21 -0800 (PST) Date: Sun, 9 Nov 2014 13:13:21 -0500 Message-ID: Subject: Fwd: [Cryptography] libkcapi: First release of kernel crypto API userspace library From: grarpamp To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 09 Nov 2014 18:18:03 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 18:13:23 -0000 ---------- Forwarded message ---------- From: Stephan Mueller Date: Sat, Nov 8, 2014 at 8:18 PM Subject: [Cryptography] libkcapi: First release of kernel crypto API userspace library To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, cryptography@metzdowd.com Cc: Herbert Xu Hi, The Linux kernel exports a Netlink interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this Netlink interface and exports easy to use APIs so that a developer does not need to consider the low-level Netlink interface handling. Its first release is available at [1]. The library does not implement any cipher algorithms. All consumer requests are sent to the kernel for processing. Results from the kernel crypto API are returned to the consumer via the library API. The kernel interface and therefore this library can be used by unprivileged processes. As the library is small, it may even be included directly into a consuming application instead of using it as a shared library. The library together with the kernel allows the use of symmetric ciphers as well as message digests and keyed message digests. Patches are prepared for submission to LKML to allow AEAD ciphers and RNGs to be used from userspace. [1] http://www.chronox.de/libkcapi.html -- Ciao Stephan _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 18:57:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9634A678; Sun, 9 Nov 2014 18:57:30 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69261A5C; Sun, 9 Nov 2014 18:57:29 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NES002KJCNKDM20@st11p02mm-asmtp002.mac.com>; Sun, 09 Nov 2014 18:57:22 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-09_03:2014-11-07,2014-11-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411090178 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: DTrace: stack() does not print kernel module functions for i386 From: Rui Paulo In-reply-to: <20141109093632.GV53947@kib.kiev.ua> Date: Sun, 09 Nov 2014 10:57:19 -0800 Content-transfer-encoding: quoted-printable Message-id: <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> References: <20141109093632.GV53947@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-dtrace@freebsd.org, freebsd-hackers@freebsd.org, Shrikanth Kamath , avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 18:57:30 -0000 On Nov 9, 2014, at 01:36, Konstantin Belousov = wrote: >=20 > On Sat, Nov 08, 2014 at 02:06:39PM -0800, Shrikanth Kamath wrote: >> I verified this on a FreeBSD 10.0 STABLE, the stack() feature does = not >> appear to print functions from kernel modules. I believe there is a >> glitch in libdtrace in the function "dt_module_update" >> (cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c). >>=20 >> The section header address computation which is currently being done >> in the function dt_module_update for elf type ET_REL, a similar >> computation needs to be done for the ET_DYN maybe. I lack background >> on the elf types but for experiment sakes I changed the line >>=20 >> @@ -948,7 +948,7 @@ dt_module_update(dtrace_hdl_t *dtp, struct = kld_fil >> #if defined(__FreeBSD__) >> mapbase =3D (uintptr_t)k_stat->address; >> gelf_getehdr(dmp->dm_elf, &ehdr); >> - is_elf_obj =3D (ehdr.e_type =3D=3D ET_REL); >> + is_elf_obj =3D (ehdr.e_type =3D=3D ET_REL) || (ehdr.e_type =3D=3D= ET_DYN); >> if (is_elf_obj) { >> dmp->dm_sec_offsets =3D >> malloc(ehdr.e_shnum * = sizeof(*dmp->dm_sec_offsets)); >>=20 >> So from a previous run where I was running a dtrace one liner >> %dtrace -n 'fbt:hwpmc:: { stack(); }' >> The output without the above change shows a sample as >>=20 >> 0 50825 pmc_find_process_descriptor:entry >> 0xc3c35bf5 <-- Address >> not matched to symbol >> kernel`syscall+0x48b >> kernel`0xc0fd2121 >>=20 >> whereas with the above nit change to include ET_DYN for section = offset >> adjustment I get the complete stack trace as >>=20 >> 0 50825 pmc_find_process_descriptor:entry >> hwpmc.ko`pmc_hook_handler+0x6a5 <--address matched to = symbol >> kernel`syscall+0x48b >> kernel`0xc0fd2121 >>=20 >> I believe without the correct section offset adjustment the following >> check in the function dtrace_lookup_by_addr fails to match the = address >> to the correct symbol >>=20 >> if (addr - dmp->dm_text_va < dmp->dm_text_size || >> addr - dmp->dm_data_va < dmp->dm_data_size || >> addr - dmp->dm_bss_va < dmp->dm_bss_size) >>=20 >> because dml->dm_text_va was not setup correctly in dt_module_update. >>=20 >> Can somebody help clarify this? >>=20 >> Reference: commit revision 210425. >=20 > I have no idea about DTrace guts, but can add one note you might find > useful. >=20 > =46rom the backtace above I can conclude that your platform is i386. > A difference between i386 and amd64 is that i386 modules are dso's > (ET_DYN), while on amd64 modules are only linked to object files > (ET_REL). The original author of the code probably tested on amd64. >=20 > You may want to special case amd64 by #ifdef, and use ET_DYN on other > arches. I agree with your analysis. I think this patch should go in with the = #ifdef __amd64__ for ET_REL. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 19:57:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7E233D1; Sun, 9 Nov 2014 19:57:06 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 716ED3F34; Sun, 9 Nov 2014 19:57:06 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id l13so16805303iga.3 for ; Sun, 09 Nov 2014 11:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=T5VAjA8s/fq4M7y2Uv3hHsT/Hqzdx17P+V2SC7QYM9E=; b=A1W4DK5Lclzih0gDmDF18dbUgHVt6GhJSnTgN5rv3bt2z+EPxEtKweqA7lHET/ouFv p4fDPOHd9GRhhu9ynbR/8dfTa+dOsVWAg9IdksHNK38kBpp6GvAfNNFigBDy8j2Ez+HL 9CeYnLuMjL/cxgUExSCYyFly5hE+OSIU/Qm0Ij7QXIKVg+R/mZRSKd7q2zWM1HRjTEDn sNogOeW7ruZCfiREUaaJwQpFmXuuFaT0IIkFV3/dP01NkLorxB4XjhNOVfR+//c3L4oG Z8XXBNqgivDXNkolljkP6TRcZ6e9SkDl3skYNIXpas4M81Fpk/ATWkmQ2z/ZZBWgftG+ nZuA== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr20085270igx.14.1415563025937; Sun, 09 Nov 2014 11:57:05 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Sun, 9 Nov 2014 11:57:05 -0800 (PST) Date: Sun, 9 Nov 2014 14:57:05 -0500 X-Google-Sender-Auth: jI5Ynmsqk4-ZcORMCfJAqM33LuM Message-ID: Subject: How thread-friendly is kevent? From: J David To: freebsd-hackers@freebsd.org, "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:57:06 -0000 How thread-friendly is kevent()? In most cases, a dedicated thread does the kevent()-ing and dispatching work to the thread pool, but at extremely high rates that thread becomes a significant bottleneck. As an example, consider a pool of, say, 17 threads on a 16 core machine all in kevent() waiting for one of 32000 open TCP connections to be read-ready. One connection becomes read-ready. How many threads will have kevent() return with that event in eventlist? Is there potential for a thundering herd problem? Limited small-scale experimentation suggests that only one thread returns per event, but it's not documented that way, so it's not clear if that behavior is intended, an implementation detail, or a coincidence that won't hold up at scale. Is this behavior at all guaranteed / by design / intentional? Although it would be ideal if so, it would also make sense to have to rely on EV_DISPATCH in multithreaded applications to prevent events from being delivered more than once, or to use EV_ONESHOT and re-add the event entirely, depending on which approach better suits the internal data structure the kernel uses for kqueue. Thanks for any advice! From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 21:17:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3047536; Sun, 9 Nov 2014 21:17:54 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34146301; Sun, 9 Nov 2014 21:17:54 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so8675698wib.7 for ; Sun, 09 Nov 2014 13:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c4FooW7pkjI+36YGm2jOK5F8GGAzZQ9hTw+n63Ejxew=; b=sdB/TAO3NcCi4+Mdm5Sdt6ABofkY7iEzhvxj0zsusqVAHNn5FIHDJr9rT3xHJsSfvo i62q9TtGDk6syb7Y0lArOIXisvMGeKlt5Goa9yWH1GGxwMTBjPS/9EhbWRKDI0phd4Xh 5Qxb7cwWQ7jZDB2unHX4hHIGhUTExnMO9i8BYOQrnsS3gq+WDjo+TjlHTQ3ogVNpesf0 5WiB0FiP8WVy29bUAnJFl/gTEm6k3PgNLpooewCsKr4ZJsco5ZXmCVCEynUyNTihjfkm 9dwn6nomm9/BQC9WOf7p7trE+oVFCRLyabFch8uYJJzNtvhwvaW3exHPkpYUMdYJTmu0 pXgg== MIME-Version: 1.0 X-Received: by 10.194.80.100 with SMTP id q4mr37052625wjx.15.1415567872583; Sun, 09 Nov 2014 13:17:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sun, 9 Nov 2014 13:17:52 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Nov 2014 13:17:52 -0800 X-Google-Sender-Auth: Cqc3dEbZvM6byXK9dl7Ww2R-E6g Message-ID: Subject: Re: How thread-friendly is kevent? From: Adrian Chadd To: J David Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 21:17:54 -0000 Hi! Are you putting the same FD into multiple threads and hoping that only one note will wake up on one listening kqueue? -adrian On 9 November 2014 11:57, J David wrote: > How thread-friendly is kevent()? > > In most cases, a dedicated thread does the kevent()-ing and > dispatching work to the thread pool, but at extremely high rates that > thread becomes a significant bottleneck. > > As an example, consider a pool of, say, 17 threads on a 16 core > machine all in kevent() waiting for one of 32000 open TCP connections > to be read-ready. One connection becomes read-ready. How many > threads will have kevent() return with that event in eventlist? Is > there potential for a thundering herd problem? > > Limited small-scale experimentation suggests that only one thread > returns per event, but it's not documented that way, so it's not clear > if that behavior is intended, an implementation detail, or a > coincidence that won't hold up at scale. > > Is this behavior at all guaranteed / by design / intentional? > > Although it would be ideal if so, it would also make sense to have to > rely on EV_DISPATCH in multithreaded applications to prevent events > from being delivered more than once, or to use EV_ONESHOT and re-add > the event entirely, depending on which approach better suits the > internal data structure the kernel uses for kqueue. > > Thanks for any advice! > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 01:50:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14467B8E; Mon, 10 Nov 2014 01:50:31 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF8ABC8; Mon, 10 Nov 2014 01:50:30 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id a13so15725305igq.5 for ; Sun, 09 Nov 2014 17:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=y9XxfzOt6T1jjRBDxP8AO1GKxJxloVywBq+qSBahY/8=; b=P1Lcuw/Imsz0vX5P6nNBorjbydE5eVmHo7gz24ULC7dKJw/2O+F8+DdKqOCm2S0gDE GpMr3nyZeY2Yi7nxDrdomkPLTPLFNh2enMf58Tyw4f315oFgKQParR43sVGQnhSME8aR dZQuKDRf8yrS2OedmJT9lpF8/L2/uVjpy1BeiKprtLIDnCg3isS7XMk0UANXRsdI9MaI dbkaDCuS7UGI16+B9qYvkAmAB48EGF3r+xZ1d5tPKffz4SYphHp2D7k9qpGai8JKCTia pjDUx0oeYq1sdZf33dCELlZ2QyHViFJ0iYIND8RL6EL8pJ6/09mnymYUvuA8ZUIvu8W/ DT/w== MIME-Version: 1.0 X-Received: by 10.42.27.9 with SMTP id h9mr33863700icc.32.1415584230248; Sun, 09 Nov 2014 17:50:30 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Sun, 9 Nov 2014 17:50:30 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Nov 2014 20:50:30 -0500 X-Google-Sender-Auth: JgWQcTlxnvwvTi2RiBwABZsngUw Message-ID: Subject: Re: How thread-friendly is kevent? From: J David To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 01:50:31 -0000 On Sun, Nov 9, 2014 at 4:17 PM, Adrian Chadd wrote: > Are you putting the same FD into multiple threads and hoping that only > one note will wake up on one listening kqueue? That's the behavior observed in testing. That's somewhat surprising, hence the question. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 04:35:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25052E5B; Mon, 10 Nov 2014 04:35:54 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89310372; Mon, 10 Nov 2014 04:35:53 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id sAA3xFTu052281; Mon, 10 Nov 2014 03:59:15 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id sAA3xFgl052280; Mon, 10 Nov 2014 03:59:15 GMT (envelope-from wkoszek) Date: Mon, 10 Nov 2014 03:59:15 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: FreeBSD + Google Code-In 2014 = we need ideas. Message-ID: <20141110035915.GA50986@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,URIBL_DBL_REDIR autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 10 Nov 2014 03:59:21 +0000 (UTC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 04:35:54 -0000 Hello, This year we'd like to participate in the Google Code-In 2014. This is Google Summer of Code, but for younger people: age range is 13--17. If you're one of them, we highly encourage you to apply! ***This year coding tasks are possible, so feel free to add those*** To submit idea which you'd like to see done in GCI, visit: http://bit.ly/FreeBSD_GCIN2014 Regardless of who you are, please use the form to submit ideas. Don't add stuff via Wiki, since this year we'll do direct import of all ideas from Google Forms. To see tasks from previous year that are yet to be copied to Google Forms: https://wiki.freebsd.org/GoogleCodeIn/2014Tasks Thanks to GCI in the previous years, we gained one more FreeBSD developer. We'd like to partcipate this year too. We need: 1) ideas. 2) mentors 3) participants. Just like in previous years we'll decide whether we're ready. Deadlines: --- November 12, 2014 - The 10-12 Mentoring organizations are announced for Google Code-in 2014 and the orgs can start entering their tasks into the Google system (the tasks will not be viewable to students until the contest opens on Dec 1). December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends --- MORE INFO: [0] http://www.google-melange.com/gci/homepage/google/gci2014 [1] gci-mentors@googlegroups.com [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 06:59:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FB57A6; Mon, 10 Nov 2014 06:59:52 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31812393; Mon, 10 Nov 2014 06:59:52 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x13so8136209wgg.8 for ; Sun, 09 Nov 2014 22:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HNvRXRSp8PanPj4UNYqdDnRHON571/q+RAiK9Oxs8oQ=; b=F4Ix89gAa8yUsiYs1r1ZDhgIBymCh33BnigFM4HCSIMXvcrQW7gJN+TgJKnQSmzkrb EMPasoS18l6UfPGUMxIh+Z/A6R/9KCWfDOrHzuFKrjJrxJudla6c9gGPusrUAlwsXaY6 aRZcmCTkl60qqFx5dtzgg3lNn5ZUT92tG8dLIcztjXrj2Acp7fHTbcifGadfRCBu8Ysy GvrEqJt0q8XKzx4AX8RveqmanRpHmTtd2cNt/GgXOSumYtu0W1+c78jlVAy8Kp5sXR5s sxo+ywuJJ2ZV3Drpe4t1Tec0pgAC5TS2MYttoFNo2bHQpawInOeHNctV8FqEcukLfW0f 6qOA== MIME-Version: 1.0 X-Received: by 10.180.87.33 with SMTP id u1mr27176011wiz.20.1415602790556; Sun, 09 Nov 2014 22:59:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sun, 9 Nov 2014 22:59:50 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Nov 2014 22:59:50 -0800 X-Google-Sender-Auth: MgJM3mh7AF2QYCzINp1gdmIlYxM Message-ID: Subject: Re: How thread-friendly is kevent? From: Adrian Chadd To: J David Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 06:59:52 -0000 On 9 November 2014 17:50, J David wrote: > On Sun, Nov 9, 2014 at 4:17 PM, Adrian Chadd wrote: >> Are you putting the same FD into multiple threads and hoping that only >> one note will wake up on one listening kqueue? > > That's the behavior observed in testing. That's somewhat surprising, > hence the question. Hm, I'm not sure if that's defined behaviour. :) -adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 07:06:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBAF52CE; Mon, 10 Nov 2014 07:06:17 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8365466A; Mon, 10 Nov 2014 07:06:17 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id hl2so8589994igb.16 for ; Sun, 09 Nov 2014 23:06:17 -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=GGwzwk8AnkoaD6E8eNy7AaerIs2b5ebnzGawBJyiFTY=; b=UutL3KdA6/HAnuICGSQRxDkIUP72NJBa6KAnNrVtQbnoLqr4PO7ucJjnRHJVwzPjP1 XLsAI0Yej5mVcFq85A9Hvbh3UwbS/NUzO/Qone+p8+TrdYPhb3SYxgtjCKYQy4EtQs2B HB+S7QROou7jpEUstOH7pp2Rv+jp7siei4yTx/vDcZpv2sVlh5Y/PERZxkWNRpH/ddZe PS6gvi0C7T//YsRRkaV0FQ3QDG1a5HF0MCw2Rcs3etPocv4PPQHWekHuov+FWBZw8HDQ UFXAfHayXK9g9BHK6Zzs0uDzqFY7UDpOx4QXI+V9y3QoYve4QUwhI3Tj+XRP5a0izIxW oUTA== MIME-Version: 1.0 X-Received: by 10.50.117.104 with SMTP id kd8mr22785185igb.3.1415603176845; Sun, 09 Nov 2014 23:06:16 -0800 (PST) Received: by 10.107.19.234 with HTTP; Sun, 9 Nov 2014 23:06:16 -0800 (PST) In-Reply-To: <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> Date: Sun, 9 Nov 2014 23:06:16 -0800 Message-ID: Subject: Re: DTrace: stack() does not print kernel module functions for i386 From: Shrikanth Kamath To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 07:06:17 -0000 On Sun, Nov 9, 2014 at 10:57 AM, Rui Paulo wrote: > On Nov 9, 2014, at 01:36, Konstantin Belousov wrote: >> >> On Sat, Nov 08, 2014 at 02:06:39PM -0800, Shrikanth Kamath wrote: >>> I verified this on a FreeBSD 10.0 STABLE, the stack() feature does not >>> appear to print functions from kernel modules. I believe there is a >>> glitch in libdtrace in the function "dt_module_update" >>> (cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c). >>> >>> The section header address computation which is currently being done >>> in the function dt_module_update for elf type ET_REL, a similar >>> computation needs to be done for the ET_DYN maybe. I lack background >>> on the elf types but for experiment sakes I changed the line >>> >>> @@ -948,7 +948,7 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_fil >>> #if defined(__FreeBSD__) >>> mapbase = (uintptr_t)k_stat->address; >>> gelf_getehdr(dmp->dm_elf, &ehdr); >>> - is_elf_obj = (ehdr.e_type == ET_REL); >>> + is_elf_obj = (ehdr.e_type == ET_REL) || (ehdr.e_type == ET_DYN); >>> if (is_elf_obj) { >>> dmp->dm_sec_offsets = >>> malloc(ehdr.e_shnum * sizeof(*dmp->dm_sec_offsets)); >>> >>> So from a previous run where I was running a dtrace one liner >>> %dtrace -n 'fbt:hwpmc:: { stack(); }' >>> The output without the above change shows a sample as >>> >>> 0 50825 pmc_find_process_descriptor:entry >>> 0xc3c35bf5 <-- Address >>> not matched to symbol >>> kernel`syscall+0x48b >>> kernel`0xc0fd2121 >>> >>> whereas with the above nit change to include ET_DYN for section offset >>> adjustment I get the complete stack trace as >>> >>> 0 50825 pmc_find_process_descriptor:entry >>> hwpmc.ko`pmc_hook_handler+0x6a5 <--address matched to symbol >>> kernel`syscall+0x48b >>> kernel`0xc0fd2121 >>> >>> I believe without the correct section offset adjustment the following >>> check in the function dtrace_lookup_by_addr fails to match the address >>> to the correct symbol >>> >>> if (addr - dmp->dm_text_va < dmp->dm_text_size || >>> addr - dmp->dm_data_va < dmp->dm_data_size || >>> addr - dmp->dm_bss_va < dmp->dm_bss_size) >>> >>> because dml->dm_text_va was not setup correctly in dt_module_update. >>> >>> Can somebody help clarify this? >>> >>> Reference: commit revision 210425. >> >> I have no idea about DTrace guts, but can add one note you might find >> useful. >> >> From the backtace above I can conclude that your platform is i386. >> A difference between i386 and amd64 is that i386 modules are dso's >> (ET_DYN), while on amd64 modules are only linked to object files >> (ET_REL). The original author of the code probably tested on amd64. >> >> You may want to special case amd64 by #ifdef, and use ET_DYN on other >> arches. > > I agree with your analysis. I think this patch should go in with the #ifdef __amd64__ for ET_REL. > > -- > Rui Paulo > > > Thanks Konstantin/Rui, I did pull up this thread https://lists.freebsd.org/pipermail/freebsd-amd64/2010-June/013034.html where it was discussed, should I file a bug report? In any case I was trying to clarify that whether ET_DYN or ET_REL the offset adjustment needs to be done true or not? -- Shrikanth R K From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 07:13:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C3F3479; Mon, 10 Nov 2014 07:13:55 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 77DA9793; Mon, 10 Nov 2014 07:13:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAA7DrvJ094454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2014 23:13:54 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAA7DrUd094453; Sun, 9 Nov 2014 23:13:53 -0800 (PST) (envelope-from jmg) Date: Sun, 9 Nov 2014 23:13:53 -0800 From: John-Mark Gurney To: J David Subject: Re: How thread-friendly is kevent? Message-ID: <20141110071353.GO24601@funkthat.com> Mail-Followup-To: J David , freebsd-hackers@freebsd.org, "freebsd-questions@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 09 Nov 2014 23:13:54 -0800 (PST) Cc: freebsd-hackers@freebsd.org, "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 07:13:55 -0000 J David wrote this message on Sun, Nov 09, 2014 at 14:57 -0500: > How thread-friendly is kevent()? > > In most cases, a dedicated thread does the kevent()-ing and > dispatching work to the thread pool, but at extremely high rates that > thread becomes a significant bottleneck. > > As an example, consider a pool of, say, 17 threads on a 16 core > machine all in kevent() waiting for one of 32000 open TCP connections > to be read-ready. One connection becomes read-ready. How many > threads will have kevent() return with that event in eventlist? Is > there potential for a thundering herd problem? It depends... kevent is a level triggered system... By default, if you don't use _ONESHOT or _DISPATCH, all threads will be woken up.. So, yes, there is potential for a thundering herd problem... > Limited small-scale experimentation suggests that only one thread > returns per event, but it's not documented that way, so it's not clear > if that behavior is intended, an implementation detail, or a > coincidence that won't hold up at scale. > > Is this behavior at all guaranteed / by design / intentional? > > Although it would be ideal if so, it would also make sense to have to > rely on EV_DISPATCH in multithreaded applications to prevent events > from being delivered more than once, or to use EV_ONESHOT and re-add > the event entirely, depending on which approach better suits the > internal data structure the kernel uses for kqueue. If you do have a single kq w/ multiple threads (you cannot have a shared kq between processes, as the fork clears out all events), you really need to use one of _DISPATCH or _ONESHOT to ensure that the event only gets delivered to a single thread.... Though if you mean how many threads will be woken up in the kernel and find that there are no events remaining as one of the other kernel threads has delivered the event, then yes, I have looked at the code, and there will be a thundering herd problem... This could be mitigated with out too much work, though the question I have is why do you have so many threads listening on the same kqueue? The most common use of this is for socket IO (there isn't much else except maybe vnodes) that you can wait on that you'd have such a highly multithreaded program... And if you do, it would make more sense to use the recent RSS work that Adrian has been working on, and have one kq per CPU w/ the proper cpu binding for that set of sockets... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 07:16:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7901C660 for ; Mon, 10 Nov 2014 07:16:44 +0000 (UTC) Received: from barracuda.ixsystems.com (mail.ixsystems.com [12.229.62.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 543DB7D7 for ; Mon, 10 Nov 2014 07:16:43 +0000 (UTC) X-ASG-Debug-ID: 1415603802-08ca0441c48c470001-P5m3U7 Received: from mail.iXsystems.com ([10.2.55.1]) by barracuda.ixsystems.com with ESMTP id gFjyOjAWNsIY9w7J (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 09 Nov 2014 23:16:42 -0800 (PST) X-Barracuda-Envelope-From: jkh@mail.turbofuzz.com X-Barracuda-RBL-Trusted-Forwarder: 10.2.55.1 Received: from [10.8.0.30] (unknown [10.8.0.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 7BF6289FC0; Sun, 9 Nov 2014 23:16:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: How thread-friendly is kevent? From: Jordan Hubbard X-ASG-Orig-Subj: Re: How thread-friendly is kevent? In-Reply-To: <20141110071353.GO24601@funkthat.com> Date: Sun, 9 Nov 2014 23:16:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <500974D4-581E-46CB-9DC8-A100AAD35F70@mail.turbofuzz.com> References: <20141110071353.GO24601@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: UNKNOWN[10.2.55.1] X-Barracuda-Start-Time: 1415603802 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.11423 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: freebsd-hackers@freebsd.org, J David , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 07:16:44 -0000 > On Nov 9, 2014, at 11:13 PM, John-Mark Gurney = wrote: >=20 > The most common use of this is for socket IO (there isn't much else > except maybe vnodes) that you can wait on that you'd have such a = highly > multithreaded program... And if you do, it would make more sense to > use the recent RSS work that Adrian has been working on, and have one > kq per CPU w/ the proper cpu binding for that set of sockets... Or just use libdispatch, which feeds a pool of worker threads from a = single event-handling source that is kind to queues. :) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 12:14:33 2014 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B341FB40; Mon, 10 Nov 2014 12:14:33 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 870C2B04; Mon, 10 Nov 2014 12:14:30 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAACEIUF052716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Nov 2014 04:14:21 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5460AC13.5060001@freebsd.org> Date: Mon, 10 Nov 2014 20:14:11 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Current , hackers@FreeBSD.ORG Subject: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 12:14:33 -0000 When I try use the libnss_winbind.so that is generated by samba 3.6 I get the following message: NSSWITCH(nss_load_module): winbind, Undefined symbol "nss_module_register". First I have to change its' name to nss_winbins.so.1 however because that is what nsswitch is looking for.... (BTW where is that documented??) then it finds it but fails as mentioned above. This same samba source generates good nss files in 8.0 but under 10 it fails.. Literally it's the same sources just checked out into a different build system. (10 vs 8). Has there been a change in the API for the nss modules? where it he API for nsswitch files documented? Julian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 16:16:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 956F8493 for ; Mon, 10 Nov 2014 16:16:25 +0000 (UTC) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.f5.com", Issuer "Entrust Certification Authority - L1C" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5131A8AD for ; Mon, 10 Nov 2014 16:16:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.07,353,1413270000"; d="scan'208,217";a="137187870" X-IPAS-Result: Al0GABXkYFTAqArr/2dsb2JhbABbgkiBGl3LaBGHTYE9AQEBAQEBcQuECYELAQwBcycEiGHQHASREYRWBYtGiz6he4I0gQMBAQE Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 10 Nov 2014 08:15:10 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 10 Nov 2014 08:15:10 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.0995.028; Mon, 10 Nov 2014 08:15:10 -0800 From: Sebastian Kuzminsky To: "freebsd-hackers@freebsd.org" Subject: 1 gig superpages Thread-Topic: 1 gig superpages Thread-Index: AQHP/QF/E8ES8FaS7ka70FoXZX0KwA== Date: Mon, 10 Nov 2014 16:15:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.239] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 16:16:25 -0000 Hello hackers, I'm announcing the availability of a branch adding support f= or 1 GB superpages to FreeBSD. https://github.com/Seb-LineRate/freebsd/commits/seb/stable-10/1-gig-pages The branch is based on work done by Line Rate Systems and F5 Networks, and = used in our LROS load-balancing product. Our product is based on FreeBSD 9.1; the branch I linked to above is our 1 = gig page support rebased onto stable/10. I probably messed something up in= the rebase, as lots of things changed both in pmap and vm since 9.1. Ther= e are also a handful of commits that i haven't gotten to yet, but they are = less consequential - just performance improvements to the buddy allocator. = I hope to push those over the next few days. It should be relatively easy to rebase the branch onto Current. This is a work in progress, and I would appreciate feedback and comments. -- Sebastian Kuzminsky From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 17:53:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4F3EA99; Mon, 10 Nov 2014 17:53:27 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A894635D; Mon, 10 Nov 2014 17:53:27 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEU0051G4C22J40@st11p02mm-asmtp001.mac.com>; Mon, 10 Nov 2014 17:52:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-10_04:2014-11-10,2014-11-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411100133 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: DTrace: stack() does not print kernel module functions for i386 From: Rui Paulo In-reply-to: Date: Mon, 10 Nov 2014 09:52:49 -0800 Content-transfer-encoding: quoted-printable Message-id: <8BE54531-7E0B-492E-ACE2-27E9F5F3C0BA@me.com> References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> To: Shrikanth Kamath X-Mailer: Apple Mail (2.1990.1) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, avg@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 17:53:27 -0000 On Nov 9, 2014, at 23:06, Shrikanth Kamath = wrote: > Thanks Konstantin/Rui, I did pull up this thread > = https://lists.freebsd.org/pipermail/freebsd-amd64/2010-June/013034.html > where it was discussed, should I file a bug report? Yes, please file a bug report. > In any case I was > trying to clarify that whether ET_DYN or ET_REL the offset adjustment > needs to be done true or not? Regarding the thread you pointed out... Maybe Andriy can clarify if he = already worked on this before. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 17:55:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 239DCBC9; Mon, 10 Nov 2014 17:55:56 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A99A8388; Mon, 10 Nov 2014 17:55:55 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so11691613wib.1 for ; Mon, 10 Nov 2014 09:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LDplYIvL8GKge1cuxlre3EWAvXgomXbhDVB0NuMmWTA=; b=i6nGZv2CHCuUOMALqWdPgnd7WYl1TRtYWHlAXtt1p3dXHC0u6ChOAqWwttqXCrrTE9 jzlHdFgKU+TWT9nfx/vgem2mc+ZmXBxKzoRUM8K4QHQLXcwSMAJmHELSOwtB7cBdARZC SRhHSKOABE3JH310MNbDSwxhHX/pK1x9esFO/LgYgzBOjrwStgpex1GXpjp81IjupwqH HRBwtIbHzrH9aA6aQk6TXtx986xm7NkZ+/zCcBkGRGYVn5Enf8PGy/Fu2DlDSOtESaUW 8tLcUI6Tb4VzpB/psdjxQjajOPUosqGAEQwftqzKTNwdZsqYxCSYWUYrrwAqXO4gNijb dlnA== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr44383867wjn.68.1415638714546; Mon, 10 Nov 2014 08:58:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Mon, 10 Nov 2014 08:58:34 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 08:58:34 -0800 X-Google-Sender-Auth: BK5SVIe5k_dTgx8KJB2vMYHy2aM Message-ID: Subject: Re: 1 gig superpages From: Adrian Chadd To: Sebastian Kuzminsky , Alan Cox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 17:55:56 -0000 Hi! Holy crap, this is great! Are you able to look at what it'd take to bring this up on -HEAD? Have a chat with Alan about the VM changes; he should be able to help you figure out what's changed in -HEAD and what needs to be polished before this thing can be committed. How do you suggest this is tested/evaluated? Thanks! -adrian On 10 November 2014 08:15, Sebastian Kuzminsky wrote: > Hello hackers, I'm announcing the availability of a branch adding support= for 1 GB superpages to FreeBSD. > > https://github.com/Seb-LineRate/freebsd/commits/seb/stable-10/1-gig-pages > > The branch is based on work done by Line Rate Systems and F5 Networks, an= d used in our LROS load-balancing product. > > Our product is based on FreeBSD 9.1; the branch I linked to above is our = 1 gig page support rebased onto stable/10. I probably messed something up = in the rebase, as lots of things changed both in pmap and vm since 9.1. Th= ere are also a handful of commits that i haven't gotten to yet, but they ar= e less consequential - just performance improvements to the buddy allocator= . I hope to push those over the next few days. > > It should be relatively easy to rebase the branch onto Current. > > > This is a work in progress, and I would appreciate feedback and comments. > > > -- > Sebastian Kuzminsky > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 20:56:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1FC5143; Mon, 10 Nov 2014 20:56:29 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83E16AB7; Mon, 10 Nov 2014 20:56:29 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so11886146wid.10 for ; Mon, 10 Nov 2014 12:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sXwuqty4ZgBa7Cq4cgR2q7XDPuymLvOLRlzyvTnPYw0=; b=T2FjRcr79v7HpS4qDMgqLNW3MlinPd/AiaROBKNsDZLbxUhdpztntuZiS3AyDUM91v /9C1PHsY9MmCUKK3SYBuZ4Tdn5eqI6bN/aC8EEWyndCIgHOpV1gS7f/hDJFP7skxGGfM 3Eh4neJ5Gg3H/hCsRFL/1OcONohs+sirB0YzG04nHGdpNnc/MxDi7dzaxDC5b8GoAJwG uBTi37orokwg7eICioBRLV/x7tbH/Fva06cK9D8i45KIXsxjjiC6Szr8lWKXyEZXhzPB XEIbeMsfZnS+k3kcbN/biQJyl6X9kGlELc1XsWy3oWdgxbevgVfumpQxCFF8SWvWC4cv vWHQ== MIME-Version: 1.0 X-Received: by 10.194.59.17 with SMTP id v17mr8314398wjq.130.1415652987273; Mon, 10 Nov 2014 12:56:27 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.220.227 with HTTP; Mon, 10 Nov 2014 12:56:27 -0800 (PST) In-Reply-To: <20141110035915.GA50986@FreeBSD.org> References: <20141110035915.GA50986@FreeBSD.org> Date: Mon, 10 Nov 2014 13:56:27 -0700 X-Google-Sender-Auth: i5twhmGcWSQHEIhy4lnKJ78cut8 Message-ID: Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. From: Alan Somers To: "Wojciech A. Koszek" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:56:30 -0000 On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wrote: > Hello, > > This year we'd like to participate in the Google Code-In 2014. This is > Google Summer of Code, but for younger people: age range is 13--17. If > you're one of them, we highly encourage you to apply! > > ***This year coding tasks are possible, so feel free to add those*** > > To submit idea which you'd like to see done in GCI, visit: > > http://bit.ly/FreeBSD_GCIN2014 > > Regardless of who you are, please use the form to submit ideas. Don't add > stuff via Wiki, since this year we'll do direct import of all ideas from > Google Forms. > > To see tasks from previous year that are yet to be copied to Google Forms: > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > Thanks to GCI in the previous years, we gained one more FreeBSD developer. > We'd like to partcipate this year too. We need: > > 1) ideas. How about converting various utility functions to use libxo? I think that's within the grasp of a high-schooler. > > 2) mentors > > 3) participants. > > Just like in previous years we'll decide whether we're ready. Deadlines: > > --- > November 12, 2014 - The 10-12 Mentoring organizations are announced for > Google Code-in 2014 and the orgs can start entering their tasks into the > Google system (the tasks will not be viewable to students until the contest > opens on Dec 1). > December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students > January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends > --- > > MORE INFO: > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > [1] gci-mentors@googlegroups.com > [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info > > -- > Wojciech A. Koszek > wkoszek@FreeBSD.czest.pl > http://FreeBSD.czest.pl/~wkoszek/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 10 23:43:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D82FDE15; Mon, 10 Nov 2014 23:43:28 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1E8DFF; Mon, 10 Nov 2014 23:43:28 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id sAANYuk1059658; Mon, 10 Nov 2014 23:34:56 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id sAANYuhg059657; Mon, 10 Nov 2014 23:34:56 GMT (envelope-from wkoszek) Date: Mon, 10 Nov 2014 23:34:56 +0000 From: "Wojciech A. Koszek" To: Alan Somers Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. Message-ID: <20141110233456.GA52541@FreeBSD.org> References: <20141110035915.GA50986@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,URIBL_DBL_REDIR autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 10 Nov 2014 23:35:02 +0000 (UTC) Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:43:29 -0000 On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: > On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wrote: > > Hello, > > > > This year we'd like to participate in the Google Code-In 2014. This is > > Google Summer of Code, but for younger people: age range is 13--17. If > > you're one of them, we highly encourage you to apply! > > > > ***This year coding tasks are possible, so feel free to add those*** > > > > To submit idea which you'd like to see done in GCI, visit: > > > > http://bit.ly/FreeBSD_GCIN2014 > > > > Regardless of who you are, please use the form to submit ideas. Don't add > > stuff via Wiki, since this year we'll do direct import of all ideas from > > Google Forms. > > > > To see tasks from previous year that are yet to be copied to Google Forms: > > > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > > > Thanks to GCI in the previous years, we gained one more FreeBSD developer. > > We'd like to partcipate this year too. We need: > > > > 1) ideas. > > > How about converting various utility functions to use libxo? I think > that's within the grasp of a high-schooler. This sounds good. Feel free to add 1 task for each such utility. Wojciech > > > > > > 2) mentors > > > > 3) participants. > > > > Just like in previous years we'll decide whether we're ready. Deadlines: > > > > --- > > November 12, 2014 - The 10-12 Mentoring organizations are announced for > > Google Code-in 2014 and the orgs can start entering their tasks into the > > Google system (the tasks will not be viewable to students until the contest > > opens on Dec 1). > > December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students > > January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends > > --- > > > > MORE INFO: > > > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > > [1] gci-mentors@googlegroups.com > > [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info > > > > -- > > Wojciech A. Koszek > > wkoszek@FreeBSD.czest.pl > > http://FreeBSD.czest.pl/~wkoszek/ > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 03:00:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ADABCDC; Tue, 11 Nov 2014 03:00:51 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10E6D23F; Tue, 11 Nov 2014 03:00:51 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id hl2so246641igb.16 for ; Mon, 10 Nov 2014 19:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=G5HBwQRVPIWPPMKfqNrE2zJ/k1S0hpnaIOeu7+GZYEc=; b=Jx/weeNVhJQpwD+K7uLEqLH+LFULYTiUHHHH3cUU82UcP4TIJwL4dgFI3fZw88kuAI +3N76QXH2wK/Q69z/S9alNquuITjkU6I76TQkxKWy4xA0faI+KcFNMOuzN8sEOq88O+D L8m/zRYmjhGJPdUgD5knRDr0w1nLur6r41MTfTI7N07PpCMW0w1rq75tUM5kV66RN/L6 wWA2ZpiDnmBReojD6yZZAtVWvrN2hH2+fU07VOJ9Oa3/Yr72+acHOmeXOM8VcYj1u0u8 RRkr/H3ne0GKVaApayvPMIphwO+eQ31a19xbiJizmoAFhf2pUbDRryXRSzs4bUimD/WF aHFw== MIME-Version: 1.0 X-Received: by 10.43.99.3 with SMTP id cq3mr4225318icc.49.1415674850388; Mon, 10 Nov 2014 19:00:50 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Mon, 10 Nov 2014 19:00:50 -0800 (PST) In-Reply-To: <20141110071353.GO24601@funkthat.com> References: <20141110071353.GO24601@funkthat.com> Date: Mon, 10 Nov 2014 22:00:50 -0500 X-Google-Sender-Auth: HoG40Do3LP_Nr6J8r9y8a_rEkQQ Message-ID: Subject: Re: How thread-friendly is kevent? From: J David To: J David , "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:00:51 -0000 On Mon, Nov 10, 2014 at 2:13 AM, John-Mark Gurney wrote: > you > really need to use one of _DISPATCH or _ONESHOT to ensure that the > event only gets delivered to a single thread.... That's what one would expect, which is why the observed behavior was so surprising. After increasing the testing load considerably, it did behave as expected (waking more than one thread for one event). But even so, the occurrences were very rare. It would wake up at most one "extra" thread in slightly less than 1 out of 100,000 events. > Though if you mean how many threads will be woken up in the kernel > and find that there are no events remaining as one of the other kernel > threads has delivered the event, then yes, I have looked at the code, > and there will be a thundering herd problem... Thanks for that, that's exactly the kind of information I was hoping to find. Is that something that can happen without any usermode-visible effects? I.e. all the threads wake up, but they almost all go back to sleep without leaving the kevent() syscall since they can see there's nothing to do anymore. If so, that would match the observed behavior, but could add up to a lot of hidden overhead. > And if you do, it would make more sense to > use the recent RSS work that Adrian has been working on, and have one > kq per CPU w/ the proper cpu binding for that set of sockets... The most recent information I was able to find: http://adrianchadd.blogspot.com/2014/10/more-rss-udp-tests-this-time-on-dell.html suggests that this work, while admirable and important, is quite some ways away from being production-stable for usermode code: "hopefully I can get my network / rss library up and running enough to prototype an RSS-aware memcached and see if it'll handle this particular workload." It's definitely something to keep an eye on, but probably not a viable approach for us right now. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 05:12:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EE3A57E; Tue, 11 Nov 2014 05:12:08 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F224B1AC; Tue, 11 Nov 2014 05:12:07 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so486002wiv.8 for ; Mon, 10 Nov 2014 21:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LU+XrniIRDh6BvRFj+Mi3A90wLvOXb/UWKc/QB1HsV4=; b=0wsPjSnxNyEeQK39XPJVovqI9XMiVo3edPK8SQo0O+seUZMoVpjOVyz153M0o7izkj ujUlakueAVcZ3ewxQ/ggj3wPf22x9xSEMos4OcpkaV53GVwdK/iZ56ipkKA6+gWDxjlw 4aDNhTLbgPQPcyNzWCdsgRHh6Q+Gc8uzKA3jzpAQ9GJpahtWiWoOMgRA1FoshVbvOBLK k+jFYTYl1hZ/zGvQ/ZxjXdPY5hloOFkrMYcECMrb7Lr63wWAplnTdrVB1+JYSd/SGmxZ Hu7AfDX2RLMUVSWGVLZJoy1Oovd2nfRmETH0YMiezh6SvI4mjhy4UCKxGWjOrDREVhuG SECA== MIME-Version: 1.0 X-Received: by 10.180.99.105 with SMTP id ep9mr37244112wib.26.1415682725850; Mon, 10 Nov 2014 21:12:05 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Mon, 10 Nov 2014 21:12:05 -0800 (PST) In-Reply-To: References: <20141110071353.GO24601@funkthat.com> Date: Mon, 10 Nov 2014 21:12:05 -0800 X-Google-Sender-Auth: v8tp0WI_6zoUkiY9Z-wXU6icZEI Message-ID: Subject: Re: How thread-friendly is kevent? From: Adrian Chadd To: J David Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 05:12:08 -0000 On 10 November 2014 19:00, J David wrote: > On Mon, Nov 10, 2014 at 2:13 AM, John-Mark Gurney wrote: >> you >> really need to use one of _DISPATCH or _ONESHOT to ensure that the >> event only gets delivered to a single thread.... > > That's what one would expect, which is why the observed behavior was > so surprising. After increasing the testing load considerably, it did > behave as expected (waking more than one thread for one event). But > even so, the occurrences were very rare. It would wake up at most one > "extra" thread in slightly less than 1 out of 100,000 events. > >> Though if you mean how many threads will be woken up in the kernel >> and find that there are no events remaining as one of the other kernel >> threads has delivered the event, then yes, I have looked at the code, >> and there will be a thundering herd problem... > > Thanks for that, that's exactly the kind of information I was hoping to find. > > Is that something that can happen without any usermode-visible > effects? I.e. all the threads wake up, but they almost all go back to > sleep without leaving the kevent() syscall since they can see there's > nothing to do anymore. If so, that would match the observed behavior, > but could add up to a lot of hidden overhead. > >> And if you do, it would make more sense to >> use the recent RSS work that Adrian has been working on, and have one >> kq per CPU w/ the proper cpu binding for that set of sockets... > > The most recent information I was able to find: > > http://adrianchadd.blogspot.com/2014/10/more-rss-udp-tests-this-time-on-dell.html > > suggests that this work, while admirable and important, is quite some > ways away from being production-stable for usermode code: > > "hopefully I can get my network / rss library up and running enough to > prototype an RSS-aware memcached and see if it'll handle this > particular workload." > > It's definitely something to keep an eye on, but probably not a viable > approach for us right now. Why? It's likely going to be heading in the direction that you'd want it to for scaling networking workloads and I could do with more users / feedback on it. (Ie, you should totally use it, because this is the direction things are likely going to head in the future, and you right now get to help shape its direction. :) -adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 09:48:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 626A05E6 for ; Tue, 11 Nov 2014 09:48:16 +0000 (UTC) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9788F1B for ; Tue, 11 Nov 2014 09:48:15 +0000 (UTC) Received: from [192.168.0.243] ([80.71.24.25]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id sAB9eqTX005694 for ; Tue, 11 Nov 2014 09:40:52 GMT (envelope-from rb@gid.co.uk) From: Bob Bishop Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 9.x/10.x i386 on Parallels 10 Message-Id: <3F48892B-E056-4C98-984A-2C9AE6296D6B@gid.co.uk> Date: Tue, 11 Nov 2014 09:40:52 +0000 To: freeBSD Hackers Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 09:48:16 -0000 Hi, Has anyone had success installing 9.x or 10.x i386 as a guest under = Parallels 10? I get the kernel stalling at: ahcich0: Poll timeout on slot 0 port 0 ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 40 serr = 00000000 cmd 1000c013 with the guest VM spinning at 100% CPU. Any ideas? -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 12:03:34 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9A5B4DC for ; Tue, 11 Nov 2014 12:03:34 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EAC6FA2 for ; Tue, 11 Nov 2014 12:03:33 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1XoAAO-000DTG-9X for hackers@freebsd.org; Tue, 11 Nov 2014 14:03:24 +0200 From: Daniel Braniss Subject: make buildkernel -j issues when cross compiling Message-Id: <0099E1C3-15EC-4C4C-AB5A-0C0FE488B728@cs.huji.ac.il> Date: Tue, 11 Nov 2014 14:03:24 +0200 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 12:03:34 -0000 hi, my dev. platform is still 9.2, and have no problems cross compiling for 9.3, but for 10, I can make buildworld -j16 with problems but make build kernel -j16 fails, without the -j it compiles ok, but slower :-) is the some fix? cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 08:29:06 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73A25944 for ; Tue, 11 Nov 2014 08:29:06 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 410BB7E3 for ; Tue, 11 Nov 2014 08:29:05 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id x19so10932975ier.2 for ; Tue, 11 Nov 2014 00:28:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T2DyZTiwLZedy5vWO/DAk1bQJKSsmitpEvUvaqHv4SU=; b=OXoDfL/zHJpdrvKdO3RYszsZiNDe0LrEX4cKTicfJhRSC+y1/2Vh7RqaM9dJvznAuq pc3ePvwcQvJHq8TxOeAuqKEUKMw3xf6o+sI1xO8nrv/WAvr9DElxQ+LU5Cf3c9gS9bFN 0pZup7IB+YYQWIett70oQq5cN+p63Pq9jK2dGO5/DshAeWkBkFD3T6upz/Dg3yR+c9lP DitbDJRZfxX5Cw2gliAeLNPgest8p1GCiDjcrbzWsgsndPrtv5/UzGtNI/Hok+CtwW21 umOE4KqBv+2FBSuYa8mcS00u1VYnzkU4aZYvhJbsOZ7Ikv2dfflKuOJhm5u5TKJ+bKvc heaA== X-Gm-Message-State: ALoCoQniSAmXIgNARLJPVkLHOKhrZMI48JI/v5oEwkzQuIEs1F/uD3gNWc0lELl9OSamyWzuyGBv X-Received: by 10.51.15.132 with SMTP id fo4mr31252936igd.36.1415694538830; Tue, 11 Nov 2014 00:28:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.19.11 with HTTP; Tue, 11 Nov 2014 00:28:38 -0800 (PST) In-Reply-To: <5460AC13.5060001@freebsd.org> References: <5460AC13.5060001@freebsd.org> From: "Timur I. Bakeyev" Date: Tue, 11 Nov 2014 09:28:38 +0100 Message-ID: Subject: Re: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8 To: Julian Elischer X-Mailman-Approved-At: Tue, 11 Nov 2014 12:12:10 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org, FreeBSD Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 08:29:06 -0000 Do you use net/samba36 port? Looks like you don't... @@ -6336,12 +6373,13 @@ NSSSONAMEVERSIONSUFFIX=".2" WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_linux.o" ;; - *freebsd[[5-9]]*) + *freebsd*) # FreeBSD winbind client is implemented as a wrapper around # the Linux version. NSSSONAMEVERSIONSUFFIX=".1" WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_freebsd.o \ ../nsswitch/winbind_nss_linux.o" + WINBIND_WINS_NSS_EXTRA_OBJS="../nsswitch/wins_freebsd.o" WINBIND_NSS="../nsswitch/nss_winbind.$SHLIBEXT" WINBIND_WINS_NSS="../nsswitch/nss_wins.$SHLIBEXT" ;; On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer wrote: > When I try use the libnss_winbind.so that is generated by samba 3.6 I get > the following message: > > NSSWITCH(nss_load_module): winbind, Undefined symbol > "nss_module_register". > > First I have to change its' name to nss_winbins.so.1 however because that > is what nsswitch is looking for.... > (BTW where is that documented??) > > then it finds it but fails as mentioned above. > > This same samba source generates good nss files in 8.0 but under 10 it > fails.. Literally it's the same sources just checked out into a different > build system. (10 vs 8). > > Has there been a change in the API for the nss modules? where it he API > for nsswitch files documented? > > Julian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 18:00:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09D7711E for ; Tue, 11 Nov 2014 18:00:43 +0000 (UTC) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC581BC for ; Tue, 11 Nov 2014 18:00:42 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id j5so7729898qga.10 for ; Tue, 11 Nov 2014 10:00:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mWgEliEb6oB4rCr8mXZNipQ2MKU2cs6Y3ser0JRiPGU=; b=UCfJ+In5Jdj9wj/HTk4+gwfOwY6f9XMSzSxW8yKkQmIxqhu2FNxaX7ahxJzmBWki/v 2hi7GkEgDuZElgWfwODlRL/D8dKKSvoYaZnsZYs5eCpuLPwok1y0Y+sUgingyzIBjOPp 2xSYcsSjAJSnwpEHxLAvokOIPslHiR06TFsQTw33XBSkgdzLoTc9qhb2CuHI2GWRfeO5 F6W9zZroSXATwa23veUIeSz/LUsqSvmkuwHsR0u/BYzgCnVxFD36WXWJDE7TkKNuAmsB AmlxSFfGiwhAMnjeofTHIrrBR9IrQ7DCJ2rWb1VwRiazkTnlEn5GyklAC1GxBOt1VOxI 0Dsw== X-Gm-Message-State: ALoCoQloCEu3pRlcsJ+bRWtfdkL1mjv+UKIW3hmzf89nOiIBCRJIyD5FZq8tsGnEJBIUl0RnpGuP X-Received: by 10.140.90.111 with SMTP id w102mr50913675qgd.88.1415728421428; Tue, 11 Nov 2014 09:53:41 -0800 (PST) Received: from blindness.ops.about.com ([209.66.78.50]) by mx.google.com with ESMTPSA id q90sm18799360qgd.4.2014.11.11.09.53.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 09:53:40 -0800 (PST) Message-ID: <54624D23.9060908@longcount.org> Date: Tue, 11 Nov 2014 12:53:39 -0500 From: Mark Saad User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: 9.x/10.x i386 on Parallels 10 References: <3F48892B-E056-4C98-984A-2C9AE6296D6B@gid.co.uk> In-Reply-To: <3F48892B-E056-4C98-984A-2C9AE6296D6B@gid.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 18:00:43 -0000 Bob On 11/11/14 04:40, Bob Bishop wrote: > Hi, > > Has anyone had success installing 9.x or 10.x i386 as a guest under Parallels 10? I get the kernel stalling at: > > ahcich0: Poll timeout on slot 0 port 0 > ahcich0: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 40 serr 00000000 cmd 1000c013 > > with the guest VM spinning at 100% CPU. Any ideas? > C an you post a config of the VM ,what version of Parallels you are using, what versions of FreeBSD you are trying, and what the host os is. I personally gave up on Parallels a while back, due to other issues with stability running Windows XP and FreeBSD on OSx. While they, SWSoft A/K/A Parallels, were first to the market for 86x virt on MacOX VirtualBox and VmWare work a lot better and with a lot less pain. Currently I use VirtualBox hosted on FreeBSD and OSX ; is free and works wonders . > -- > Bob Bishop > rb@gid.co.uk > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 22:52:59 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 454D940B; Tue, 11 Nov 2014 22:52:59 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 47879ADF; Tue, 11 Nov 2014 22:52:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA18712; Wed, 12 Nov 2014 00:54:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XoKIo-000JGo-1P; Wed, 12 Nov 2014 00:52:46 +0200 Message-ID: <5462930B.7060907@FreeBSD.org> Date: Tue, 11 Nov 2014 14:51:55 -0800 From: Andriy Gapon User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rui Paulo , Shrikanth Kamath Subject: Re: DTrace: stack() does not print kernel module functions for i386 References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> <8BE54531-7E0B-492E-ACE2-27E9F5F3C0BA@me.com> In-Reply-To: <8BE54531-7E0B-492E-ACE2-27E9F5F3C0BA@me.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@FreeBSD.org, freebsd-dtrace@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:52:59 -0000 On 10/11/2014 09:52, Rui Paulo wrote: > On Nov 9, 2014, at 23:06, Shrikanth Kamath wrote: >> Thanks Konstantin/Rui, I did pull up this thread >> https://lists.freebsd.org/pipermail/freebsd-amd64/2010-June/013034.html >> where it was discussed, should I file a bug report? > > Yes, please file a bug report. > >> In any case I was >> trying to clarify that whether ET_DYN or ET_REL the offset adjustment >> needs to be done true or not? > > Regarding the thread you pointed out... Maybe Andriy can clarify if he already worked on this before. As I recall (and the mentioned thread seems to confirm it) I encountered the problem on amd64 and I fixed it there. I never knew that there was any problem like that on other platforms including i386. This is the first time I hear about that. So, obviously I did not do any work or any testing on other platforms. Please feel free to test and fix. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 06:52:46 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 764967ED; Wed, 12 Nov 2014 06:52:46 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 52748224; Wed, 12 Nov 2014 06:52:45 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAC6qV5I060273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Nov 2014 22:52:35 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <546303A2.2070401@freebsd.org> Date: Wed, 12 Nov 2014 14:52:18 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Timur I. Bakeyev" Subject: Re: samba/NSSWITCH interaction in fbsd 10 vs fbsd 8 References: <5460AC13.5060001@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org, FreeBSD Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 06:52:46 -0000 On 11/11/14, 4:28 PM, Timur I. Bakeyev wrote: > Do you use net/samba36 port? Looks like you don't... It occurred to me after posting to check the port and I found this.. The company decided to go the independent route before I joined so they don't use the port. They have a huge set of diffs to samba so it kind of makes sense. > > @@ -6336,12 +6373,13 @@ > NSSSONAMEVERSIONSUFFIX=".2" > WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_linux.o" > ;; > - *freebsd[[5-9]]*) > + *freebsd*) > # FreeBSD winbind client is implemented as a wrapper > around > # the Linux version. > NSSSONAMEVERSIONSUFFIX=".1" > WINBIND_NSS_EXTRA_OBJS="../nsswitch/winbind_nss_freebsd.o \ > ../nsswitch/winbind_nss_linux.o" > + WINBIND_WINS_NSS_EXTRA_OBJS="../nsswitch/wins_freebsd.o" > WINBIND_NSS="../nsswitch/nss_winbind.$SHLIBEXT" > WINBIND_WINS_NSS="../nsswitch/nss_wins.$SHLIBEXT" > ;; > > > On Mon, Nov 10, 2014 at 1:14 PM, Julian Elischer > wrote: > > When I try use the libnss_winbind.so that is generated by samba > 3.6 I get the following message: > > NSSWITCH(nss_load_module): winbind, Undefined symbol > "nss_module_register". > > First I have to change its' name to nss_winbins.so.1 however > because that is what nsswitch is looking for.... > (BTW where is that documented??) > > then it finds it but fails as mentioned above. > > This same samba source generates good nss files in 8.0 but under > 10 it fails.. Literally it's the same sources just checked out > into a different build system. (10 vs 8). > > Has there been a change in the API for the nss modules? where it > he API for nsswitch files documented? > > Julian > _______________________________________________ > freebsd-current@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org > " > > From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 08:49:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 220F7D32; Wed, 12 Nov 2014 08:49:11 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EB62CF12; Wed, 12 Nov 2014 08:49:10 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAC8n91c025370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 00:49:09 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAC8n9qv025369; Wed, 12 Nov 2014 00:49:09 -0800 (PST) (envelope-from jmg) Date: Wed, 12 Nov 2014 00:49:09 -0800 From: John-Mark Gurney To: J David Subject: Re: How thread-friendly is kevent? Message-ID: <20141112084909.GV24601@funkthat.com> Mail-Followup-To: J David , "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" References: <20141110071353.GO24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Nov 2014 00:49:10 -0800 (PST) Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 08:49:11 -0000 J David wrote this message on Mon, Nov 10, 2014 at 22:00 -0500: > On Mon, Nov 10, 2014 at 2:13 AM, John-Mark Gurney wrote: > > you > > really need to use one of _DISPATCH or _ONESHOT to ensure that the > > event only gets delivered to a single thread.... > > That's what one would expect, which is why the observed behavior was > so surprising. After increasing the testing load considerably, it did > behave as expected (waking more than one thread for one event). But > even so, the occurrences were very rare. It would wake up at most one > "extra" thread in slightly less than 1 out of 100,000 events. This is odd... I would expect that the event w/o _ONESHOT and _DISPATCH to be delivered many times... Is it possible you have locks in your userland side of things that make this less likely? > > Though if you mean how many threads will be woken up in the kernel > > and find that there are no events remaining as one of the other kernel > > threads has delivered the event, then yes, I have looked at the code, > > and there will be a thundering herd problem... > > Thanks for that, that's exactly the kind of information I was hoping to find. > > Is that something that can happen without any usermode-visible > effects? I.e. all the threads wake up, but they almost all go back to > sleep without leaving the kevent() syscall since they can see there's > nothing to do anymore. If so, that would match the observed behavior, > but could add up to a lot of hidden overhead. I have an idea that should only be a few lines of changes that would prevent all the threads waking up... As we lock the kq before doing the wakeup, we can change KQ_SLEEP from a flag to a count for how many threads are sleeping for an event, and if non-zero, do a wakeup_one... Then when kqueue_scan is about to exit, check to see if there are still events and threads waiting, and then do another wakeup_one... Currently, KQ_SLEEP is only a flag, so we have to do wakeup to make sure everyone wakes up... Well, if you don't have _ONESHOT and _DISPATCH, any changes I make should make it more reliable that all threads get the events dispatched to them... :) > > And if you do, it would make more sense to > > use the recent RSS work that Adrian has been working on, and have one > > kq per CPU w/ the proper cpu binding for that set of sockets... > > The most recent information I was able to find: > > http://adrianchadd.blogspot.com/2014/10/more-rss-udp-tests-this-time-on-dell.html > > suggests that this work, while admirable and important, is quite some > ways away from being production-stable for usermode code: > > "hopefully I can get my network / rss library up and running enough to > prototype an RSS-aware memcached and see if it'll handle this > particular workload." > > It's definitely something to keep an eye on, but probably not a viable > approach for us right now. True... But some of this is making sure you only run enough threads as necessary... As the kq lock is a single lock, having extra threads that don't really do much work only increasing contention and other issues... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 22:12:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A81D5F24; Wed, 12 Nov 2014 22:12:27 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DBA7C; Wed, 12 Nov 2014 22:12:27 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id a13so83812igq.3 for ; Wed, 12 Nov 2014 14:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ei2ct2OT1OIYaWh2GpBdXZnRaWAv2LjVd1Kw5UpW560=; b=nWUt2wY6nScoztcvSzOGajFGLpDz/SLGZc9H15YzDcT1OZCsG9LerLp9AgvfJ5+rHi RCeOmO5zds5koz1ZJ+BgOZODNigq92+pFKri9jMvcWuDaKApDK9RoTJ3fbudSISKkq+z pdyrt8qPXfbWgOsOvZhXz3OHoNCBzpj2OLUeXyrven730sMnNqY9PkSEm0OzjkSH8Y/2 onlvd5VCObnPYAg/45WuRDiGKEMXwatdBVsxQnycBpw1e1i+sYpP5prEQ7Nd4iAE5sHw wt92TqEe3T5IWfXDaKD5Hc5v6ID8msHNN8wEmcvCOBjn525hkZ8O9qnQx1wKqctBnfTo gpVQ== MIME-Version: 1.0 X-Received: by 10.50.110.4 with SMTP id hw4mr43095406igb.14.1415830346882; Wed, 12 Nov 2014 14:12:26 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Wed, 12 Nov 2014 14:12:26 -0800 (PST) In-Reply-To: References: <20141110071353.GO24601@funkthat.com> Date: Wed, 12 Nov 2014 17:12:26 -0500 X-Google-Sender-Auth: ticUhn_dH6WwJ4HvT_k_hfYMN5E Message-ID: Subject: Re: How thread-friendly is kevent? From: J David To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:12:27 -0000 On Tue, Nov 11, 2014 at 12:12 AM, Adrian Chadd wrote: > (Ie, you should totally use it, because this is the direction things > are likely going to head in the future, and you right now get to help > shape its direction. :) This isn't a project for the future, it is a 9.3-based project that will be in production as soon as it is finished and tested. Weeks, not months or years. Using that type of bleeding edge stuff in production is the sort of thing an organization only does if they have an Adrian Chadd on staff who intimately understands every detail of it, someone who can shepherd use of it and who can basically guarantee that any problems that come up can be handled very quickly as their #1 drop-everything priority. That's not the case here. From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 22:14:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC3FD134; Wed, 12 Nov 2014 22:14:06 +0000 (UTC) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6C3F95; Wed, 12 Nov 2014 22:14:06 +0000 (UTC) Received: by mail-yk0-f171.google.com with SMTP id 142so1491760ykq.2 for ; Wed, 12 Nov 2014 14:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Y+2x2nwM6zHvfeRMvEQbfoM1ZLkwmYkR0UEflLr3zmQ=; b=FzRnJSP7K+4DiyQMEQyz3eY0fa4I50YjcSl054EgoZay8FvjMWcSy8Zrqfi3Er+IIG IJ8NtvUn143sfdGk+rNNuGf3XgT20EOLkFFWIOMrlDtfTkjqV1l9E7Pbi9MhHV8xQyJJ j+jz877M5GeiSL0sFa4cbVhQWU09wCVhDGXK/Hwj+OV3mQMa2qdWQPbx7cvLuLbBbdkW Ok05rjvpulb8OhBpW94zPVvuf6vxzsMe4OnkI2LegPbuizW00t44MwvKTWORVKuqJuN2 +ABKswyCUWdwPaJVvc34WFnY25gbPQD0eiy34qMm0JjF+SBVtM6ctLPuxcLDNmka5GOV shEA== MIME-Version: 1.0 X-Received: by 10.170.204.23 with SMTP id v23mr2471923yke.115.1415830445720; Wed, 12 Nov 2014 14:14:05 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Wed, 12 Nov 2014 14:14:05 -0800 (PST) In-Reply-To: <20141112084909.GV24601@funkthat.com> References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Date: Wed, 12 Nov 2014 14:14:05 -0800 X-Google-Sender-Auth: tnQpuFxg5QTBjCubGUuVR910Z5E Message-ID: Subject: Re: How thread-friendly is kevent? From: "K. Macy" To: J David , "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:14:07 -0000 This may not be related, but it's interesting: a client I worked for many years ago switched from kqueue to poll for their web server because kqueue did not distribute the workload evenly. I imagine this is unchanged. -K On Wed, Nov 12, 2014 at 12:49 AM, John-Mark Gurney wrote: > J David wrote this message on Mon, Nov 10, 2014 at 22:00 -0500: >> On Mon, Nov 10, 2014 at 2:13 AM, John-Mark Gurney wrote: >> > you >> > really need to use one of _DISPATCH or _ONESHOT to ensure that the >> > event only gets delivered to a single thread.... >> >> That's what one would expect, which is why the observed behavior was >> so surprising. After increasing the testing load considerably, it did >> behave as expected (waking more than one thread for one event). But >> even so, the occurrences were very rare. It would wake up at most one >> "extra" thread in slightly less than 1 out of 100,000 events. > > This is odd... I would expect that the event w/o _ONESHOT and _DISPATCH > to be delivered many times... Is it possible you have locks in your > userland side of things that make this less likely? > >> > Though if you mean how many threads will be woken up in the kernel >> > and find that there are no events remaining as one of the other kernel >> > threads has delivered the event, then yes, I have looked at the code, >> > and there will be a thundering herd problem... >> >> Thanks for that, that's exactly the kind of information I was hoping to find. >> >> Is that something that can happen without any usermode-visible >> effects? I.e. all the threads wake up, but they almost all go back to >> sleep without leaving the kevent() syscall since they can see there's >> nothing to do anymore. If so, that would match the observed behavior, >> but could add up to a lot of hidden overhead. > > I have an idea that should only be a few lines of changes that would > prevent all the threads waking up... As we lock the kq before doing > the wakeup, we can change KQ_SLEEP from a flag to a count for how many > threads are sleeping for an event, and if non-zero, do a wakeup_one... > Then when kqueue_scan is about to exit, check to see if there are > still events and threads waiting, and then do another wakeup_one... > > Currently, KQ_SLEEP is only a flag, so we have to do wakeup to make > sure everyone wakes up... > > Well, if you don't have _ONESHOT and _DISPATCH, any changes I make > should make it more reliable that all threads get the events dispatched > to them... :) > >> > And if you do, it would make more sense to >> > use the recent RSS work that Adrian has been working on, and have one >> > kq per CPU w/ the proper cpu binding for that set of sockets... >> >> The most recent information I was able to find: >> >> http://adrianchadd.blogspot.com/2014/10/more-rss-udp-tests-this-time-on-dell.html >> >> suggests that this work, while admirable and important, is quite some >> ways away from being production-stable for usermode code: >> >> "hopefully I can get my network / rss library up and running enough to >> prototype an RSS-aware memcached and see if it'll handle this >> particular workload." >> >> It's definitely something to keep an eye on, but probably not a viable >> approach for us right now. > > True... But some of this is making sure you only run enough threads as > necessary... As the kq lock is a single lock, having extra threads that > don't really do much work only increasing contention and other issues... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 22:24:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33971576; Wed, 12 Nov 2014 22:24:03 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC2D01B3; Wed, 12 Nov 2014 22:24:02 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id x19so14650967ier.19 for ; Wed, 12 Nov 2014 14:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=1nSLXNyihbjkx2Vx5ikZIVjfnDI2BVH3kybRAktw2Ec=; b=u1YJXiR83k9/5ST8rBm29vDOkWpI1wngL5qmW76zdE4JlPxZ/SwsrGe8czeGBuhjrP 2GRV67AfwOnaR03wmulCffhTqQjwBkN4sNlLvqzo5NQvgjxHN97FgxKuSgngQSHJC2Py G3ZGXg9dSgy8FtV/SZnBd3R+29bKA77gCnLTrK5AELT7MGCXR5vYQHAhdgg/QwcHJb7j iZqB/wEn66/IC3kgiz2JyjCrahuMmrVVQs21GFfoDz2s7e3nEDHxiLBOHpEVonvHR+rC K+ZPNAqW0jTlznZ69GFJZ+Htwf31LgHlngEM7fNgPvMTx3PSJUUhgovnIqEk2cNeHiG3 RizQ== MIME-Version: 1.0 X-Received: by 10.50.66.227 with SMTP id i3mr43418093igt.25.1415831042507; Wed, 12 Nov 2014 14:24:02 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Wed, 12 Nov 2014 14:24:02 -0800 (PST) In-Reply-To: <20141112084909.GV24601@funkthat.com> References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Date: Wed, 12 Nov 2014 17:24:02 -0500 X-Google-Sender-Auth: 2khuzCpSBX4KFNUMXIjW6tdAguU Message-ID: Subject: Re: How thread-friendly is kevent? From: J David To: J David , "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:24:03 -0000 On Wed, Nov 12, 2014 at 3:49 AM, John-Mark Gurney wrote: > This is odd... I would expect that the event w/o _ONESHOT and _DISPATCH > to be delivered many times... Is it possible you have locks in your > userland side of things that make this less likely? Nope, the test code is (intentionally) entirely lock-free in userland. > I have an idea that should only be a few lines of changes that would > prevent all the threads waking up... As we lock the kq before doing > the wakeup, we can change KQ_SLEEP from a flag to a count for how many > threads are sleeping for an event, and if non-zero, do a wakeup_one... > Then when kqueue_scan is about to exit, check to see if there are > still events and threads waiting, and then do another wakeup_one... This sounds like it could optimize some workloads at substantial penalties for others. If pursued, maybe it needs its own flag. > Currently, KQ_SLEEP is only a flag, so we have to do wakeup to make > sure everyone wakes up... > > Well, if you don't have _ONESHOT and _DISPATCH, any changes I make > should make it more reliable that all threads get the events dispatched > to them... :) Using _DISPATCH is no problem, although a solution that didn't require two kevent()-calls per event would obviously be better when every syscall matters. Albeit that is largely an issue on VM's where the syscall penalty is artificially large. In production, this will of course run on bare metal. The other option is do wrap kevent() with a mutex on the user side. That's what Apache does with accept(), IIRC. > But some of this is making sure you only run enough threads as > necessary... That's almost always true. But, almost always, determining the correct value of "enough" requires a blood sacrifice. :) Thanks! From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 22:29:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06C068D5; Wed, 12 Nov 2014 22:29:49 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF136218; Wed, 12 Nov 2014 22:29:48 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id tp5so14663311ieb.29 for ; Wed, 12 Nov 2014 14:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d88zpEN5C19K/L1ZcBUFO0gO4HWy3TLpiyQQculc7TA=; b=Q4lL+MQPyg1AhatkXUqFT2Q5FhaCZDtORveClADTPxfIe0NNgdEMM/JRwc2s0XuQjf ztC2v2xaSRtQ8dNKw7sAltbEDWsScTalPBnu1v9I4Ozy/lP7g2fG56X2y2pVt0q6QIvn vX5JqlHDH7JjTqzpBAc8VsM6VtuIZ06trW9Qzqgyjg9ueQDmdMcy+XQpFL68S8T6vreG JXLNAlZqjy8TDqtKnVuacxorjRbKHQGA63hjYDd+JOni9fViKGbr7fTgvmQT7f1KaQUm A8OJrNNY00qmFmHe8E5gnJlaa0W5e+HLO/KvHvdGUbAbuUZnsLkblKmIWnI5mvFFKWPe AOtQ== MIME-Version: 1.0 X-Received: by 10.107.11.129 with SMTP id 1mr51732741iol.18.1415831388124; Wed, 12 Nov 2014 14:29:48 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Wed, 12 Nov 2014 14:29:48 -0800 (PST) In-Reply-To: References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Date: Wed, 12 Nov 2014 17:29:48 -0500 X-Google-Sender-Auth: tVQRAEk5UL9NKjsTZgCQNHXjr0w Message-ID: Subject: Re: How thread-friendly is kevent? From: J David To: "K. Macy" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:29:49 -0000 On Wed, Nov 12, 2014 at 5:14 PM, K. Macy wrote: > This may not be related, but it's interesting: a client I worked for > many years ago switched from kqueue to poll for their web server > because kqueue did not distribute the workload evenly. I imagine this > is unchanged. It looks pretty good in testing: $ ./kqtest server Server thread ends after 2630979 events. Server thread ends after 2600452 events. Server thread ends after 2525542 events. Server thread ends after 2418386 events. Server thread ends after 2524895 events. $ That's a small-scale test on a VM with two CPU's running five threads, but the results appear to hold. (This is using the _DISPATCH model.) Thanks! From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 22:31:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABF06BB1; Wed, 12 Nov 2014 22:31:54 +0000 (UTC) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 692B32FD; Wed, 12 Nov 2014 22:31:54 +0000 (UTC) Received: by mail-yk0-f174.google.com with SMTP id q9so1497709ykb.5 for ; Wed, 12 Nov 2014 14:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pQpbvL1Y2Ghy+mFNY45f+N7SgDZqRLSnPeBxdZWSJEk=; b=Az5uJEvrTbY9Gpqs+029AtZMR5vbngvGkyo26Rfix34SGyJwFESIZoloUm06mxa6/h d3tISkWN/oSk1+JRKfzo85kvUa5Q16xRsSl07xRWXzH05GLzPNJLlxyYuVR0XiXIrfL+ m1+UM/4/pz5h2IsNrZHuPeH1+NpQGLVhKut1IoqR+3pj3rI3+aqFodAe587wugnfj6Sq ydb2c7LztjOUW8tkUrO58CJEr4scmoUC6GHUFvGSeRVRZqBWGNKR3t9EORgZbZWs9fPG dpQl920YSK7v3fylmzV3sIa8yQWNJet+6rbMmHbIhXN74OaXyBheGdj8y775eIeyHDtQ iZxQ== MIME-Version: 1.0 X-Received: by 10.170.122.203 with SMTP id o194mr25648651ykb.10.1415831513005; Wed, 12 Nov 2014 14:31:53 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Wed, 12 Nov 2014 14:31:52 -0800 (PST) In-Reply-To: References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Date: Wed, 12 Nov 2014 14:31:52 -0800 X-Google-Sender-Auth: foF3vQSJz3-SspixqtjQYZEhPbQ Message-ID: Subject: Re: How thread-friendly is kevent? From: "K. Macy" To: J David Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:31:54 -0000 Well, this was 8 cores with 45 or so processes. I'm not saying it won't scale smoothly, but it did not in the past for lighttpd. Perhaps it would have with some changes. -K On Wed, Nov 12, 2014 at 2:29 PM, J David wrote: > On Wed, Nov 12, 2014 at 5:14 PM, K. Macy wrote: >> This may not be related, but it's interesting: a client I worked for >> many years ago switched from kqueue to poll for their web server >> because kqueue did not distribute the workload evenly. I imagine this >> is unchanged. > > It looks pretty good in testing: > > $ ./kqtest server > > Server thread ends after 2630979 events. > > Server thread ends after 2600452 events. > > Server thread ends after 2525542 events. > > Server thread ends after 2418386 events. > > Server thread ends after 2524895 events. > > $ > > > That's a small-scale test on a VM with two CPU's running five threads, > but the results appear to hold. (This is using the _DISPATCH model.) > > Thanks! From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 23:54:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A5D8D8; Wed, 12 Nov 2014 23:54:50 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C713D12; Wed, 12 Nov 2014 23:54:50 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so14283315iec.24 for ; Wed, 12 Nov 2014 15:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KzRtcpM+7b7ffsfPRZOtK19WUhlqecrqc34dBk7dMcY=; b=wkfdK+HmxkvTk6d8UBvkVIGh2ifAYCAvOlP4UK9xy2RuPGFNzM13wul+a4kFl7DYd/ Ibk8sQRn9srayj4q51fUyfAOmcrXc965yvkqBgH1C98KQpWYZCSjI8IdlTSogcBJ5vQu 1ZXtKAN43aiRncgWU+eCkIDHQSAmxBQmXlEHRD1o6xkL3KCyiUprWVYk5/qSJxaJYuzV fpPfnzxapyO4frr6wCew2sipohltgC3W1lLY1vAyCCaT7VlKEOLsxo3YdYYG8ggXzGPe KBtdJMhJIuxzhxMj8UfeNcIkmm+4MzXdEheU1KJ1YiZROqRjlbRgF070rqYIgtQ8RYqp bEDA== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr43600815igx.14.1415836489371; Wed, 12 Nov 2014 15:54:49 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Wed, 12 Nov 2014 15:54:49 -0800 (PST) In-Reply-To: References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Date: Wed, 12 Nov 2014 18:54:49 -0500 X-Google-Sender-Auth: -GfO5ISEUfnIrhtV7HiQ3hKeBy8 Message-ID: Subject: Re: How thread-friendly is kevent? From: J David To: "K. Macy" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:54:50 -0000 On Wed, Nov 12, 2014 at 5:31 PM, K. Macy wrote: > Well, this was 8 cores with 45 or so processes. Here's the bench test on a 16 (physical) core machine with 24 threads: Server thread ends after 853093 events. Server thread ends after 834169 events. Server thread ends after 826117 events. Server thread ends after 824130 events. Server thread ends after 826998 events. Server thread ends after 838043 events. Server thread ends after 859163 events. Server thread ends after 844742 events. Server thread ends after 821916 events. Server thread ends after 807776 events. Server thread ends after 805819 events. Server thread ends after 840685 events. Server thread ends after 847173 events. Server thread ends after 834560 events. Server thread ends after 833862 events. Server thread ends after 842143 events. Server thread ends after 866425 events. Server thread ends after 813094 events. Server thread ends after 833364 events. Server thread ends after 805277 events. Server thread ends after 816654 events. Server thread ends after 834174 events. Server thread ends after 851322 events. Server thread ends after 839701 events. This particular test is CPU bound, so more threads don't make much sense, but they also don't make much difference as far as balance. The results are equally even with 128 threads, though the time wasted in kqflxw and context switching is *enormously* larger, aptly demonstrating what John-Mark was talking about. So it seems fairly scalable, at least as of 9.3-STABLE. Good work, whoever it was! Thanks! From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 01:23:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5333532; Thu, 13 Nov 2014 01:23:16 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30EB87C5; Thu, 13 Nov 2014 01:23:16 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id r20so6756505wiv.4 for ; Wed, 12 Nov 2014 17:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2NOtbKUkjDHilfwFIRlIRUCK5U5uvCcsQG4pmoTdcJE=; b=uAO5WecCncZQWT/oz2bZ+sZr3zvk7Z9WHu0xrbdJGPRzdoxKca4dAIcffioo02AtEt W/fhSqkNKjhw1sChov8YhI2xOTuOdRohrDm32I3IkmeNtilJI1LbEZ7EV5K6/dP/kTSF t/aq7jLx0Q2lmcGhQ6S+eLJ7+llFJm4U9ruYXtgLG1Qf7RVcLUhLCsrNAk3uX600BJlH OESjQh3oUiDNXZIbhyESG5CLN/JWTh6vEMN9gTwCxaY5j36xVcw0KImhzK6bEs88fiQw uogawVEUeI0Zs46qqMFoK/N6TJiNg4Fzf+2lI10fKwW6T6EvCHK2JLiBuNbAg/oEt9Md hvFQ== MIME-Version: 1.0 X-Received: by 10.180.92.169 with SMTP id cn9mr35049083wib.26.1415841794557; Wed, 12 Nov 2014 17:23:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 12 Nov 2014 17:23:14 -0800 (PST) In-Reply-To: References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Date: Wed, 12 Nov 2014 17:23:14 -0800 X-Google-Sender-Auth: 1goJdnRGgOKKim-A4NWyM3nvJQA Message-ID: Subject: Re: How thread-friendly is kevent? From: Adrian Chadd To: J David Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "K. Macy" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 01:23:16 -0000 On 12 November 2014 15:54, J David wrote: > On Wed, Nov 12, 2014 at 5:31 PM, K. Macy wrote: >> Well, this was 8 cores with 45 or so processes. > > Here's the bench test on a 16 (physical) core machine with 24 threads: > > Server thread ends after 853093 events. > Server thread ends after 834169 events. > Server thread ends after 826117 events. > Server thread ends after 824130 events. > Server thread ends after 826998 events. > Server thread ends after 838043 events. > Server thread ends after 859163 events. > Server thread ends after 844742 events. > Server thread ends after 821916 events. > Server thread ends after 807776 events. > Server thread ends after 805819 events. > Server thread ends after 840685 events. > Server thread ends after 847173 events. > Server thread ends after 834560 events. > Server thread ends after 833862 events. > Server thread ends after 842143 events. > Server thread ends after 866425 events. > Server thread ends after 813094 events. > Server thread ends after 833364 events. > Server thread ends after 805277 events. > Server thread ends after 816654 events. > Server thread ends after 834174 events. > Server thread ends after 851322 events. > Server thread ends after 839701 events. > > This particular test is CPU bound, so more threads don't make much > sense, but they also don't make much difference as far as balance. > The results are equally even with 128 threads, though the time wasted > in kqflxw and context switching is *enormously* larger, aptly > demonstrating what John-Mark was talking about. > > So it seems fairly scalable, at least as of 9.3-STABLE. Good work, > whoever it was! Have you done any profiling of the system? At that many CPUs I'd expect you'd see the shared kqueue fileops lock causing some contending. Hopefully the RSS stuff is mature enough in -11 for you to consider using. I'm trying to address both work load balancing / steering as well as CPU affinity scaling issues. I'd love to see this stuff presented at a BSD conference. Are you at all interested in talking some more about it? -adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 08:25:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 204DF532; Thu, 13 Nov 2014 08:25:53 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E9A48262; Thu, 13 Nov 2014 08:25:52 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAD8PoGO040027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 00:25:51 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAD8PoEC040026; Thu, 13 Nov 2014 00:25:50 -0800 (PST) (envelope-from jmg) Date: Thu, 13 Nov 2014 00:25:50 -0800 From: John-Mark Gurney To: J David Subject: Re: How thread-friendly is kevent? Message-ID: <20141113082550.GG24601@funkthat.com> Mail-Followup-To: J David , "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 13 Nov 2014 00:25:51 -0800 (PST) Cc: "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 08:25:53 -0000 J David wrote this message on Wed, Nov 12, 2014 at 17:24 -0500: > On Wed, Nov 12, 2014 at 3:49 AM, John-Mark Gurney wrote: > > This is odd... I would expect that the event w/o _ONESHOT and _DISPATCH > > to be delivered many times... Is it possible you have locks in your > > userland side of things that make this less likely? > > Nope, the test code is (intentionally) entirely lock-free in userland. > > > I have an idea that should only be a few lines of changes that would > > prevent all the threads waking up... As we lock the kq before doing > > the wakeup, we can change KQ_SLEEP from a flag to a count for how many > > threads are sleeping for an event, and if non-zero, do a wakeup_one... > > Then when kqueue_scan is about to exit, check to see if there are > > still events and threads waiting, and then do another wakeup_one... > > This sounds like it could optimize some workloads at substantial > penalties for others. If pursued, maybe it needs its own flag. It really wouldn't be a penalty as the other thread couldn't make progress since the kq lock was held and would be waiting for the kq lock anyways... The only penalty might be the delay in waking up, but that'd be minor... But there was already a penalty for the cross processor read to find out that the lock is held... > > Currently, KQ_SLEEP is only a flag, so we have to do wakeup to make > > sure everyone wakes up... > > > > Well, if you don't have _ONESHOT and _DISPATCH, any changes I make > > should make it more reliable that all threads get the events dispatched > > to them... :) > > Using _DISPATCH is no problem, although a solution that didn't require > two kevent()-calls per event would obviously be better when every > syscall matters. Albeit that is largely an issue on VM's where the > syscall penalty is artificially large. In production, this will of > course run on bare metal. If you care about that, I'd recommend you have a thread local buffer that you add enable events to, and then when you get back to your main loop, you add all of these waiting events.. > The other option is do wrap kevent() with a mutex on the user side. > That's what Apache does with accept(), IIRC. kevent effectively provides that lock internally... > > But some of this is making sure you only run enough threads as > > necessary... > > That's almost always true. But, almost always, determining the > correct value of "enough" requires a blood sacrifice. :) :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 08:34:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C66947B7; Thu, 13 Nov 2014 08:34:27 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 769AF39F; Thu, 13 Nov 2014 08:34:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAD8YQY7040106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 00:34:26 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAD8YQbn040105; Thu, 13 Nov 2014 00:34:26 -0800 (PST) (envelope-from jmg) Date: Thu, 13 Nov 2014 00:34:26 -0800 From: John-Mark Gurney To: "K. Macy" Subject: Re: How thread-friendly is kevent? Message-ID: <20141113083426.GH24601@funkthat.com> Mail-Followup-To: "K. Macy" , J David , "freebsd-hackers@freebsd.org" , "freebsd-questions@freebsd.org" References: <20141110071353.GO24601@funkthat.com> <20141112084909.GV24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 13 Nov 2014 00:34:26 -0800 (PST) Cc: "freebsd-hackers@freebsd.org" , J David , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 08:34:27 -0000 K. Macy wrote this message on Wed, Nov 12, 2014 at 14:14 -0800: > This may not be related, but it's interesting: a client I worked for > many years ago switched from kqueue to poll for their web server > because kqueue did not distribute the workload evenly. I imagine this > is unchanged. I've heard this before... But no one has been able to say that this caused a performance issue... If they were able to switch to poll w/o significant performance overhead, then they probably weren't dealing w/ thousands upon thousands of fd's, or they were already doing thread balancing by having each thread wait on a subset of fd's... It's also the standard problem of batching vs. single processing... If you call kevent w/ room for 8 threads, the first thread will try to take them all if it can... If that same thread finishes before more events come in, then you really don't have that much more work to do for the other threads... You can obviously decrease this batching, but then other issues come into play... If someone has some solid numbers and can test patches, I'd be interested in helping them work on it, but until then... > On Wed, Nov 12, 2014 at 12:49 AM, John-Mark Gurney wrote: > > J David wrote this message on Mon, Nov 10, 2014 at 22:00 -0500: > >> On Mon, Nov 10, 2014 at 2:13 AM, John-Mark Gurney wrote: > >> > you > >> > really need to use one of _DISPATCH or _ONESHOT to ensure that the > >> > event only gets delivered to a single thread.... > >> > >> That's what one would expect, which is why the observed behavior was > >> so surprising. After increasing the testing load considerably, it did > >> behave as expected (waking more than one thread for one event). But > >> even so, the occurrences were very rare. It would wake up at most one > >> "extra" thread in slightly less than 1 out of 100,000 events. > > > > This is odd... I would expect that the event w/o _ONESHOT and _DISPATCH > > to be delivered many times... Is it possible you have locks in your > > userland side of things that make this less likely? > > > >> > Though if you mean how many threads will be woken up in the kernel > >> > and find that there are no events remaining as one of the other kernel > >> > threads has delivered the event, then yes, I have looked at the code, > >> > and there will be a thundering herd problem... > >> > >> Thanks for that, that's exactly the kind of information I was hoping to find. > >> > >> Is that something that can happen without any usermode-visible > >> effects? I.e. all the threads wake up, but they almost all go back to > >> sleep without leaving the kevent() syscall since they can see there's > >> nothing to do anymore. If so, that would match the observed behavior, > >> but could add up to a lot of hidden overhead. > > > > I have an idea that should only be a few lines of changes that would > > prevent all the threads waking up... As we lock the kq before doing > > the wakeup, we can change KQ_SLEEP from a flag to a count for how many > > threads are sleeping for an event, and if non-zero, do a wakeup_one... > > Then when kqueue_scan is about to exit, check to see if there are > > still events and threads waiting, and then do another wakeup_one... > > > > Currently, KQ_SLEEP is only a flag, so we have to do wakeup to make > > sure everyone wakes up... > > > > Well, if you don't have _ONESHOT and _DISPATCH, any changes I make > > should make it more reliable that all threads get the events dispatched > > to them... :) > > > >> > And if you do, it would make more sense to > >> > use the recent RSS work that Adrian has been working on, and have one > >> > kq per CPU w/ the proper cpu binding for that set of sockets... > >> > >> The most recent information I was able to find: > >> > >> http://adrianchadd.blogspot.com/2014/10/more-rss-udp-tests-this-time-on-dell.html > >> > >> suggests that this work, while admirable and important, is quite some > >> ways away from being production-stable for usermode code: > >> > >> "hopefully I can get my network / rss library up and running enough to > >> prototype an RSS-aware memcached and see if it'll handle this > >> particular workload." > >> > >> It's definitely something to keep an eye on, but probably not a viable > >> approach for us right now. > > > > True... But some of this is making sure you only run enough threads as > > necessary... As the kq lock is a single lock, having extra threads that > > don't really do much work only increasing contention and other issues... > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 10:16:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F5B5B97 for ; Thu, 13 Nov 2014 10:16:59 +0000 (UTC) Received: from kerio.tuxis.nl (alcyone.saas.tuxis.net [31.3.111.19]) by mx1.freebsd.org (Postfix) with ESMTP id 912ED1CF for ; Thu, 13 Nov 2014 10:16:57 +0000 (UTC) X-Footer: dHV4aXMubmw= Received: from [31.3.104.222] ([31.3.104.222]) by kerio.tuxis.nl (Kerio Connect 8.4.0 RC 1) for freebsd-hackers@freebsd.org; Thu, 13 Nov 2014 10:46:46 +0100 Date: Thu, 13 Nov 2014 10:46:46 +0100 Subject: Slow nfsd write performance, tweaks needed X-Mailer: Kerio Connect 8.4.0 RC 1/Kerio Connect client X-User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36 Message-ID: <2826701214-10966@kerio.tuxis.nl> X-Priority: 3 Importance: Normal MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 MIME-Version: 1.0 From: Mark Schouten To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="=-QclVn6YRa6m6ltd6cwMJ" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 10:16:59 -0000 --=-QclVn6YRa6m6ltd6cwMJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I am in the process of switching from a ZFS On Linux-based NFS-server to a = FreeBSD-based NFS-server. The FreeBSD implementation of ZFS is way superiou= r over ZoL, and the box serves as storage for a virtualizationplatform, so = stability is welcome. :) The box is stable, but performs terribly. Surely, I'm doing something wrong= , but I would like some tips and tricks to speed things up. Here's my setup: CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (HyperThreading is enabled) RAM: 64GB NIC: 2x igb in lagg0 (loadbalancing) Disks:=C2=A0 export1 =C2=A0 =C2=A0 1.81T =C2=A0 914G =C2=A0 942G =C2=A0 =C2=A049% =C2=A0= 1.00x =C2=A0ONLINE =C2=A0- =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - =C2=A0 =C2=A0 da0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 da1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - =C2=A0 =C2=A0 da2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 da3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 mirror =C2=A0 =C2=A09.94G =C2=A0 173M =C2=A09.77G =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - =C2=A0 =C2=A0 da4p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2= =A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 da5p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2= =A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - cache =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2= =A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2= =A0- =C2=A0 da4p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0 = =C2=A0 =C2=A0 =C2=A0 - =C2=A0 da5p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0 = =C2=A0 =C2=A0 =C2=A0 - da0-3 are 1TB WDs da4-5 are 240GB=C2=A0Samsung SSD 840s Here's (related) info from rc.conf. nfs_server_enable=3D"YES" nfs_server_flags=3D"-u -t -n 128" rpcbind_enable=3D"YES" mountd_enable=3D"YES" rpc_lockd_enable=3D"YES" rpc_statd_enable=3D"YES" I have compression enabled on all the ZFS-filesystems, and jumboframes are = enabled on the nics. As soon as one of the (Linux) clients start to do some IO, NFS responsetime= s go up bigtime (yesterday up to 13 seconds), while the hardware is pretty = much idle, I must be doing something very wrong. I'm mostly a Linux-guy, so= any hit with a FreeBSD cluebat is appreciated. Regards, --=C2=A0 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl= --=-QclVn6YRa6m6ltd6cwMJ Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: Electronic Signature S/MIME Content-Transfer-Encoding: base64 MIIRwQYJKoZIhvcNAQcCoIIRsjCCEa4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDt4w ggUbMIIEA6ADAgECAhAsv+VdGX6YsSHI/WRu2j2JMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE0MDcwMTAwMDAwMFoXDTE1MDcwMTIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNbWFya0B0dXhpcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANHu3SxlMZOG5GA0/mqtRXR1QmWwhUXzmCIprI0IPtSBWSA31YBJ5qcmXRhLzaiTB3Fr UpIGkW5aAZnDms9DD64kasF3oZE00Fvfnj/BDGbw098px1PukKfg4hasbTaELAjQTSUj8xRSHzKk VVynvLA/YmyRT/+u3ueK4wdaxcej241xH6mNfZeiKMAvbkv6Tm9vdup0BtqqbRSKcnc01KKrspun Eh73jLIUhP21uJv8vuOTxS1I9zJSlhIcMCEapjBQ+26cQl+s+qBuAs/LP3UPVytSbxvicdhDxtqH npN2h3jJ/+J86zGfQi8bG7EamsULTGHkbgIJL9AdKZRgAKECAwEAAaOCAd0wggHZMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR+dMZE22X/SMCyTxYzIP+NMZBNXTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+BDW1hcmtA dHV4aXMubmwwDQYJKoZIhvcNAQEFBQADggEBAIB8FhqaML1EzfvgNwwHDC3k0ICeMerOncgee6uJ KLxwU2mstttX5jtAmgK9RuDOu+TrMkkpF2yxYMTPpSM8nL7r+N/kdogu5Bustol8WTsW1e5vs+Nh hJYFORk113ouur1kSjXuHF8TWy+/PjFJBS/xm/H+/fkghppRU+4Dj2IReUBvlexAPYr4VDxjV7AD xPOXqTQkP15LWGvhTz2YVbJ3IAVOyUNkRhr9QwzToUxXa9k/QAOpXMuvS74AT2RBV/YCEEx7ebRD MAR6lZcbYiV8sXv1ASbnMdO3Fh2F98g+5rJn5PfFH8qLpapsZx0I2/axtSG09QMDJqXd3Ab6NpEw ggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hf ZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrh o/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0 mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MP bXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRc WzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwu dXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwu Y3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29t L1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ 9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1 ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B 080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAg TmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5 MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p 1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K 2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bU MSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjK aJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0 tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDeg NYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUG CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1 ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj 2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTGCAqswggKnAgEBMIGo MIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAsv+VdGX6YsSHI/WRu2j2JMAkG BSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQx MTEzMDk0NjQ2WjAjBgkqhkiG9w0BCQQxFgQUPo3SVwy+S51c0ND7Zx2wkgUN7SAweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEARym0kCXV9a/59Yex9QRRlIkcFO2fGwimJlHV6AfsVvLsEBD6T3fn svhuJaaAjwMv/6d6+2sF51patDV0q7W+A0hQNqQwUTRyuj/lAZaY7jmdSd/Gx/iFemYSCWkFzdU4 ml6Tl1oJ4H3YwtoFxWTiS9SJixxCCCq94n8B65fySj4l5XuKvFV3nyO2eMf9wPblOCEvGC/+vcnQ Aom6fT8bsuXFBaLYBIe+A6DbhNKXd1UHEGV/LRDAiZwIRcsaGFcSll8Rl/gbCYAo3+e8qXknw9yB jrUuLiaOeAd4uRuYIulJpsqOg2VjCidQYwYLhqd5giFNsfc3//wyIlPdvkPWVw== --=-QclVn6YRa6m6ltd6cwMJ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 10:32:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FF8F193 for ; Thu, 13 Nov 2014 10:32:52 +0000 (UTC) Received: from kerio.tuxis.nl (alcyone.saas.tuxis.net [31.3.111.19]) by mx1.freebsd.org (Postfix) with ESMTP id 04F30658 for ; Thu, 13 Nov 2014 10:32:50 +0000 (UTC) X-Footer: dHV4aXMubmw= Received: from [31.3.104.222] ([31.3.104.222]) by kerio.tuxis.nl (Kerio Connect 8.4.0 RC 1) for freebsd-hackers@freebsd.org; Thu, 13 Nov 2014 11:32:47 +0100 Date: Thu, 13 Nov 2014 11:32:47 +0100 Subject: Re: Slow nfsd write performance, tweaks needed X-Mailer: Kerio Connect 8.4.0 RC 1/Kerio Connect client X-User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36 Message-ID: <2830524724-18108@kerio.tuxis.nl> X-Priority: 3 Importance: Normal In-Reply-To: <2826701214-10966@kerio.tuxis.nl> MIME-Version: 1.0 From: Mark Schouten To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="=-xA/YYSEnc6bWW1W5YXhH" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 10:32:52 -0000 --=-xA/YYSEnc6bWW1W5YXhH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, Mark Schouten , 13-11-2014 11:17:I am in the process of swi= tching from a ZFS On Linux-based NFS-server to a FreeBSD-based NFS-server. = The FreeBSD implementation of ZFS is way superiour over ZoL, and the box se= rves as storage for a virtualizationplatform, so stability is welcome. :)=20 I've been noticed that this is the incorrect mailinglist for these question= s. #freenode directed me this way, please ignore my question (or feel free = to respond in offlist). Regards, --=C2=A0 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl= --=-xA/YYSEnc6bWW1W5YXhH Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: Electronic Signature S/MIME Content-Transfer-Encoding: base64 MIIRwQYJKoZIhvcNAQcCoIIRsjCCEa4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDt4w ggUbMIIEA6ADAgECAhAsv+VdGX6YsSHI/WRu2j2JMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE0MDcwMTAwMDAwMFoXDTE1MDcwMTIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNbWFya0B0dXhpcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANHu3SxlMZOG5GA0/mqtRXR1QmWwhUXzmCIprI0IPtSBWSA31YBJ5qcmXRhLzaiTB3Fr UpIGkW5aAZnDms9DD64kasF3oZE00Fvfnj/BDGbw098px1PukKfg4hasbTaELAjQTSUj8xRSHzKk VVynvLA/YmyRT/+u3ueK4wdaxcej241xH6mNfZeiKMAvbkv6Tm9vdup0BtqqbRSKcnc01KKrspun Eh73jLIUhP21uJv8vuOTxS1I9zJSlhIcMCEapjBQ+26cQl+s+qBuAs/LP3UPVytSbxvicdhDxtqH npN2h3jJ/+J86zGfQi8bG7EamsULTGHkbgIJL9AdKZRgAKECAwEAAaOCAd0wggHZMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR+dMZE22X/SMCyTxYzIP+NMZBNXTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+BDW1hcmtA dHV4aXMubmwwDQYJKoZIhvcNAQEFBQADggEBAIB8FhqaML1EzfvgNwwHDC3k0ICeMerOncgee6uJ KLxwU2mstttX5jtAmgK9RuDOu+TrMkkpF2yxYMTPpSM8nL7r+N/kdogu5Bustol8WTsW1e5vs+Nh hJYFORk113ouur1kSjXuHF8TWy+/PjFJBS/xm/H+/fkghppRU+4Dj2IReUBvlexAPYr4VDxjV7AD xPOXqTQkP15LWGvhTz2YVbJ3IAVOyUNkRhr9QwzToUxXa9k/QAOpXMuvS74AT2RBV/YCEEx7ebRD MAR6lZcbYiV8sXv1ASbnMdO3Fh2F98g+5rJn5PfFH8qLpapsZx0I2/axtSG09QMDJqXd3Ab6NpEw ggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hf ZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrh o/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0 mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MP bXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRc WzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwu dXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwu Y3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29t L1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ 9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1 ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B 080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAg TmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5 MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p 1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K 2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bU MSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjK aJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0 tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDeg NYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUG CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1 ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj 2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTGCAqswggKnAgEBMIGo MIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAsv+VdGX6YsSHI/WRu2j2JMAkG BSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQx MTEzMTAzMjQ3WjAjBgkqhkiG9w0BCQQxFgQUUVwE+6KyQFBMVfLyymWi7eRybdYweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAR2eyWfT39hYNLbqRqqOeqYK9p63cErNXCHfZicUJzH4pEF9LTypn rOB39nxvgrCP4FnDyxJjPfFfj/UILSu2lny0Wi5rNH9xYr0H27eQy4kz1u8tBjUyHCGQ+ka5i2Z1 nwp1KCiHiJUFPhpOCROeV/vvbJ0tg+zDhfhPayTUMdVmOYebmJ6PXBGIZ6ZYwMI9e1H6N/2iMO/L T3GUosIQEs4XX+OmIqme25Dm+40kIgnDwWoZNMLwlRT21mcfHC3VOxTKis7mOIG7Rdx2/riBxK8S wYav9jbrazhxmHODZ32b9MXk2R+5c2hEV0mQEV8QlIqooDyfI3+b7tIP1kgKGA== --=-xA/YYSEnc6bWW1W5YXhH-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 10:49:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F36C7A3 for ; Thu, 13 Nov 2014 10:49:01 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0096.outbound.protection.outlook.com [207.46.100.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37A66805 for ; Thu, 13 Nov 2014 10:49:00 +0000 (UTC) Received: from DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) by DM2PR04MB479.namprd04.prod.outlook.com (10.141.105.21) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 10:33:47 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.59]) by DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.59]) with mapi id 15.01.0016.006; Thu, 13 Nov 2014 10:33:47 +0000 From: Mike Gelfand To: "hackers@freebsd.org" Subject: [BUG] Getting path to program binary sometimes fails Thread-Topic: [BUG] Getting path to program binary sometimes fails Thread-Index: AQHP/y1OF6HbydE23kCBwyNP5wFRKQ== Date: Thu, 13 Nov 2014 10:33:47 +0000 Message-ID: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.140.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB479; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB479; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(71364002)(189002)(15202345003)(15395725005)(46102003)(19273905006)(83716003)(54356999)(21056001)(64706001)(92726001)(97736003)(92566001)(87936001)(2656002)(50986999)(4396001)(31966008)(66066001)(20776003)(15975445006)(82746002)(101416001)(33656002)(19300405004)(86362001)(110136001)(229853001)(19580395003)(122556002)(2351001)(107886001)(99396003)(105586002)(36756003)(450100001)(99286002)(107046002)(77096003)(2501002)(77156002)(40100003)(62966003)(106356001)(95666004)(120916001)(106116001)(104396001)(562404015)(85282002)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR04MB479; H:DM2PR04MB477.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <32E5664FD0405142AB9C77883A046CC5@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: logicnow.com X-Mailman-Approved-At: Thu, 13 Nov 2014 12:20:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 10:49:01 -0000 Hello, I=92ve been advised (on #freebsd @FreeNode) to send a mail here with detail= s. I=92m observing a weird issue where process may not able to determine path = to its own binary (and maybe other process binaries as well, thought I didn= =92t test that) under some [not yet clear to me] conditions. The code I use= in production first tries to call sysctl(KERN_PROC_PATHNAME) and if that f= ails fallback to call readlink(/proc/curproc/file); at some point both call= s fail with ENOENT. This happens on two FreeBSD 9 (vanilla 9.1-RELEASE and = 9.2-RELEASE) machines, and never happens (or at least never happened in ove= r two years) on FreeBSD 8 (vanilla 8.3-RELEASE-p3); all machines are amd64.= I=92ve been able to reduce the test case to a sample program [1] which I r= un using a sample script [2], and the error then happens when I=92m buildin= g clang-devel from ports. I=92ve also recorded a screencast [3]. Is this a know defect? Do you need any other information other than provide= d above to reproduce? [1] http://mikedld.com/f/selfpath/selfpath.c [2] http://mikedld.com/f/selfpath/selfpath.sh [3] http://mikedld.com/f/selfpath/selfpath.mov Kind regards, Mike From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 12:58:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B7A4EB1 for ; Thu, 13 Nov 2014 12:58:58 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 320ED781 for ; Thu, 13 Nov 2014 12:58:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAHupZFSDaFve/2dsb2JhbABbg2JZBIMCyWiHUwKBNQEBAQEBfYQCAQEBAwEjSAMLGQIYAgINGQJZBhOIOAmcf5xflhoBAQEBAQEBAwEBAQEBAQEBARmBLY8eFQEzB4J3gVQFhSIDhmaQFoNEkSmECoQaHzCBB0GBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,377,1413259200"; d="scan'208";a="166404282" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 13 Nov 2014 07:57:48 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C07FEB405F; Thu, 13 Nov 2014 07:57:48 -0500 (EST) Date: Thu, 13 Nov 2014 07:57:48 -0500 (EST) From: Rick Macklem To: Mark Schouten Message-ID: <1690681228.12559777.1415883468777.JavaMail.root@uoguelph.ca> In-Reply-To: <2826701214-10966@kerio.tuxis.nl> Subject: Re: Slow nfsd write performance, tweaks needed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 12:58:58 -0000 Mark Schouten wrote: > Hi, >=20 >=20 > I am in the process of switching from a ZFS On Linux-based NFS-server > to a FreeBSD-based NFS-server. The FreeBSD implementation of ZFS is > way superiour over ZoL, and the box serves as storage for a > virtualizationplatform, so stability is welcome. :) >=20 >=20 > The box is stable, but performs terribly. Surely, I'm doing something > wrong, but I would like some tips and tricks to speed things up. >=20 >=20 >=20 >=20 > Here's my setup: > CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (HyperThreading is > enabled) > RAM: 64GB > NIC: 2x igb in lagg0 (loadbalancing) > Disks: >=20 > export1 =C2=A0 =C2=A0 1.81T =C2=A0 914G =C2=A0 942G =C2=A0 =C2=A049% =C2= =A01.00x =C2=A0ONLINE =C2=A0- > =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 mirror =C2=A0 =C2=A09.94G =C2=A0 173M =C2=A09.77G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da4p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da5p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > cache =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 = =C2=A0- > =C2=A0 da4p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0= =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 da5p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0= =C2=A0 =C2=A0 =C2=A0 - >=20 >=20 > da0-3 are 1TB WDs > da4-5 are 240GB=C2=A0Samsung SSD 840s >=20 >=20 > Here's (related) info from rc.conf. >=20 > nfs_server_enable=3D"YES" > nfs_server_flags=3D"-u -t -n 128" > rpcbind_enable=3D"YES" > mountd_enable=3D"YES" > rpc_lockd_enable=3D"YES" > rpc_statd_enable=3D"YES" >=20 >=20 >=20 >=20 > I have compression enabled on all the ZFS-filesystems, and > jumboframes are enabled on the nics. >=20 >=20 > As soon as one of the (Linux) clients start to do some IO, NFS > responsetimes go up bigtime (yesterday up to 13 seconds), while the > hardware is pretty much idle, I must be doing something very wrong. > I'm mostly a Linux-guy, so any hit with a FreeBSD cluebat is > appreciated. >=20 When an NFS server demonstrates terrible performance, it is usually a problem with the underlying network fabric. Possibilities include: - A problem with TSO enabled network interface doing I/O of near 64K. (This should be mostly fixed in recent code, but you didn't mention what version of FreeBSD you are using, so...) Workarounds: disable TSO or make sure all your clients are using rsize=3D32768,wsize=3D32768 - A problem with your network interface device driver. Workaround: Try a different kind of network interface. (You didn't give hardware specs for the server, so we don't know what kind of NIC you are using. FreeBSD doesn't have the marketshare of Linux, so the drivers vary greatly depending on the hardware.) - I have no idea what effect jumboframes might have. If possible, I suggest you try disabling them. I have no expertise on the ZFS side, so maybe someone else will make some suggestions there. Good luck with it, rick ps: There is no "ideal" mailing list for NFS stuff. Most would use either freebsd-stable@ or freebsd-current@, depending on whether they are using a stable release or -head. Others might use freebsd-fs@. >=20 > Regards, >=20 >=20 > -- > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > Mark Schouten | Tuxis Internet Engineering > KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ > T: 0318 200208 | info@tuxis.nl From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 13:00:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBECCFA1 for ; Thu, 13 Nov 2014 13:00:16 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B2E6B792 for ; Thu, 13 Nov 2014 13:00:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAKiqZFSDaFve/2dsb2JhbABbg2JZBIMCyWiHUwKBNQEBAQEBfYQCAQEBAwEjVgUUAhgCAg0ZAlkGE4g4CZ0EnF+WGgEBAQEBAQEDAQEBAQEBAQEBGYEtjx4VATMHgneBVAWFIgOGZpAWmHeEGh8wgQdBgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,377,1413259200"; d="scan'208";a="166405315" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 13 Nov 2014 08:00:15 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A72CBB40AE; Thu, 13 Nov 2014 08:00:15 -0500 (EST) Date: Thu, 13 Nov 2014 08:00:15 -0500 (EST) From: Rick Macklem To: Mark Schouten Message-ID: <1841043385.12560911.1415883615679.JavaMail.root@uoguelph.ca> In-Reply-To: <2826701214-10966@kerio.tuxis.nl> Subject: Re: Slow nfsd write performance, tweaks needed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 13:00:17 -0000 Mark Schouten wrote: > Hi, >=20 >=20 > I am in the process of switching from a ZFS On Linux-based NFS-server > to a FreeBSD-based NFS-server. The FreeBSD implementation of ZFS is > way superiour over ZoL, and the box serves as storage for a > virtualizationplatform, so stability is welcome. :) >=20 >=20 > The box is stable, but performs terribly. Surely, I'm doing something > wrong, but I would like some tips and tricks to speed things up. >=20 >=20 >=20 >=20 > Here's my setup: > CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (HyperThreading is > enabled) > RAM: 64GB > NIC: 2x igb in lagg0 (loadbalancing) Oops, I didn't see this before my last post. igb had problems with the 64K TSO issue and I'd try to get rid of lagg as well. (You might be much better off just using a single net interface without lagg.) Again, good luck with it, rick > Disks: >=20 > export1 =C2=A0 =C2=A0 1.81T =C2=A0 914G =C2=A0 942G =C2=A0 =C2=A049% =C2= =A01.00x =C2=A0ONLINE =C2=A0- > =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 mirror =C2=A0 =C2=A09.94G =C2=A0 173M =C2=A09.77G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da4p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da5p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > cache =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 = =C2=A0- > =C2=A0 da4p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0= =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 da5p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0= =C2=A0 =C2=A0 =C2=A0 - >=20 >=20 > da0-3 are 1TB WDs > da4-5 are 240GB=C2=A0Samsung SSD 840s >=20 >=20 > Here's (related) info from rc.conf. >=20 > nfs_server_enable=3D"YES" > nfs_server_flags=3D"-u -t -n 128" > rpcbind_enable=3D"YES" > mountd_enable=3D"YES" > rpc_lockd_enable=3D"YES" > rpc_statd_enable=3D"YES" >=20 >=20 >=20 >=20 > I have compression enabled on all the ZFS-filesystems, and > jumboframes are enabled on the nics. >=20 >=20 > As soon as one of the (Linux) clients start to do some IO, NFS > responsetimes go up bigtime (yesterday up to 13 seconds), while the > hardware is pretty much idle, I must be doing something very wrong. > I'm mostly a Linux-guy, so any hit with a FreeBSD cluebat is > appreciated. >=20 >=20 > Regards, >=20 >=20 > -- > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > Mark Schouten | Tuxis Internet Engineering > KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ > T: 0318 200208 | info@tuxis.nl From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 13:10:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C2E7455 for ; Thu, 13 Nov 2014 13:10:41 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 12F6F91D for ; Thu, 13 Nov 2014 13:10:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAEysZFSDaFve/2dsb2JhbABbg2JZBIMCyWiHUwKBNQEBAQEBfYQCAQEBAwEjVgUUAhgCAg0ZAlkGE4g4CZ0KnF+WGAEBAQEBAQEDAQEBAQEBAQEBGYEtjx4VATMHgneBVAWFIgOGZpAWg0SDT5FkhBofMIEHQYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,377,1413259200"; d="scan'208";a="167822535" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Nov 2014 08:09:31 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C6180B40D6; Thu, 13 Nov 2014 08:09:31 -0500 (EST) Date: Thu, 13 Nov 2014 08:09:31 -0500 (EST) From: Rick Macklem To: Mark Schouten Message-ID: <54043890.12566825.1415884171801.JavaMail.root@uoguelph.ca> In-Reply-To: <2826701214-10966@kerio.tuxis.nl> Subject: Re: Slow nfsd write performance, tweaks needed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 13:10:41 -0000 Mark Schouten wrote: > Hi, >=20 >=20 > I am in the process of switching from a ZFS On Linux-based NFS-server > to a FreeBSD-based NFS-server. The FreeBSD implementation of ZFS is > way superiour over ZoL, and the box serves as storage for a > virtualizationplatform, so stability is welcome. :) >=20 >=20 > The box is stable, but performs terribly. Surely, I'm doing something > wrong, but I would like some tips and tricks to speed things up. >=20 >=20 >=20 >=20 > Here's my setup: > CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (HyperThreading is > enabled) > RAM: 64GB > NIC: 2x igb in lagg0 (loadbalancing) Oops again. I don't think igb had the 64K TSO problem (I get the Intel nics confused;-), but I would definitely suggest trying without lagg and then disabling jumbo packets, if possible. Please let us know if you fix the problem, rick > Disks: >=20 > export1 =C2=A0 =C2=A0 1.81T =C2=A0 914G =C2=A0 942G =C2=A0 =C2=A049% =C2= =A01.00x =C2=A0ONLINE =C2=A0- > =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 mirror =C2=A0 =C2=A0 928G =C2=A0 457G =C2=A0 471G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 mirror =C2=A0 =C2=A09.94G =C2=A0 173M =C2=A09.77G =C2=A0 =C2=A0 = =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da4p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 =C2=A0 da5p1 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 - > cache =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2=A0- =C2=A0 = =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=A0 = =C2=A0- > =C2=A0 da4p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0= =C2=A0 =C2=A0 =C2=A0 - > =C2=A0 da5p2 =C2=A0 =C2=A0 =C2=A0223G =C2=A0 223G =C2=A0 =C2=A0 8M =C2=A0= =C2=A0 =C2=A0 =C2=A0 - >=20 >=20 > da0-3 are 1TB WDs > da4-5 are 240GB=C2=A0Samsung SSD 840s >=20 >=20 > Here's (related) info from rc.conf. >=20 > nfs_server_enable=3D"YES" > nfs_server_flags=3D"-u -t -n 128" > rpcbind_enable=3D"YES" > mountd_enable=3D"YES" > rpc_lockd_enable=3D"YES" > rpc_statd_enable=3D"YES" >=20 >=20 >=20 >=20 > I have compression enabled on all the ZFS-filesystems, and > jumboframes are enabled on the nics. >=20 >=20 > As soon as one of the (Linux) clients start to do some IO, NFS > responsetimes go up bigtime (yesterday up to 13 seconds), while the > hardware is pretty much idle, I must be doing something very wrong. > I'm mostly a Linux-guy, so any hit with a FreeBSD cluebat is > appreciated. >=20 >=20 > Regards, >=20 >=20 > -- > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > Mark Schouten | Tuxis Internet Engineering > KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ > T: 0318 200208 | info@tuxis.nl From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 13:14:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66B78592 for ; Thu, 13 Nov 2014 13:14:46 +0000 (UTC) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21B44945 for ; Thu, 13 Nov 2014 13:14:46 +0000 (UTC) Received: by mail-yk0-f171.google.com with SMTP id 142so2039592ykq.2 for ; Thu, 13 Nov 2014 05:14:45 -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=A/1P3+OZHFW7PdILPPUFq5Lj8mYquGgnUNkVCJnrB2I=; b=i6uQngxEb0Q8guTRIv88dmfbN1zOeCefROvCEo2N506LfWoEqloK4wjZeYd0czY2Kf Vd3LMH+ibACFFVOjAMAilzB3dOI+fOf4lNdmQq9knsec8HYf5+AKmnIHnF58nw5HeZHb xedL+HbSUVi4+aCy44QyVLgeStJc3BtAW061W1BykBXjX7JTyuzL57xWtkC63ZBONJ1v SZpht1i4WiuLKgzIu3h1TGltaxVTHHIiKWuFbMO3frw3Vedf7jQiISvbNYNKsRqzZ0mk zDS/nSMjNtla0gan7Q2KohxWFXPHudmkBpMX6HhBfQmKYI+FGUPyrLXWFn4Tpkmw2N8r LOOA== MIME-Version: 1.0 X-Received: by 10.170.196.72 with SMTP id n69mr2747882yke.41.1415884485344; Thu, 13 Nov 2014 05:14:45 -0800 (PST) Received: by 10.170.84.133 with HTTP; Thu, 13 Nov 2014 05:14:45 -0800 (PST) In-Reply-To: <1841043385.12560911.1415883615679.JavaMail.root@uoguelph.ca> References: <2826701214-10966@kerio.tuxis.nl> <1841043385.12560911.1415883615679.JavaMail.root@uoguelph.ca> Date: Thu, 13 Nov 2014 05:14:45 -0800 Message-ID: Subject: Re: Slow nfsd write performance, tweaks needed From: Mehmet Erol Sanliturk To: Rick Macklem Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Hackers , Mark Schouten X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 13:14:46 -0000 On Thu, Nov 13, 2014 at 5:00 AM, Rick Macklem wrote: > Mark Schouten wrote: > > Hi, > > > > > > I am in the process of switching from a ZFS On Linux-based NFS-server > > to a FreeBSD-based NFS-server. The FreeBSD implementation of ZFS is > > way superiour over ZoL, and the box serves as storage for a > > virtualizationplatform, so stability is welcome. :) > > > > > > The box is stable, but performs terribly. Surely, I'm doing something > > wrong, but I would like some tips and tricks to speed things up. > > > > > > > > > > Here's my setup: > > CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (HyperThreading is > > enabled) > > RAM: 64GB > > NIC: 2x igb in lagg0 (loadbalancing) > Oops, I didn't see this before my last post. igb had problems with > the 64K TSO issue and I'd try to get rid of lagg as well. > (You might be much better off just using a single net interface > without lagg.) > > Again, good luck with it, rick > > > Disks: > > > > export1 1.81T 914G 942G 49% 1.00x ONLINE - > > mirror 928G 457G 471G - > > da0 - - - - > > da1 - - - - > > mirror 928G 457G 471G - > > da2 - - - - > > da3 - - - - > > mirror 9.94G 173M 9.77G - > > da4p1 - - - - > > da5p1 - - - - > > cache - - - - - - > > da4p2 223G 223G 8M - > > da5p2 223G 223G 8M - > > > > > > da0-3 are 1TB WDs > > da4-5 are 240GB Samsung SSD 840s > > > > > > Here's (related) info from rc.conf. > > > > nfs_server_enable="YES" > > nfs_server_flags="-u -t -n 128" > > rpcbind_enable="YES" > > mountd_enable="YES" > > rpc_lockd_enable="YES" > > rpc_statd_enable="YES" > > > > > > > > > > I have compression enabled on all the ZFS-filesystems, and > > jumboframes are enabled on the nics. > > > > > > As soon as one of the (Linux) clients start to do some IO, NFS > > responsetimes go up bigtime (yesterday up to 13 seconds), while the > > hardware is pretty much idle, I must be doing something very wrong. > > I'm mostly a Linux-guy, so any hit with a FreeBSD cluebat is > > appreciated. > > > > > > Regards, > > > > > > -- > > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > > Mark Schouten | Tuxis Internet Engineering > > KvK: 61527076 | http://www.tuxis.nl/ > > T: 0318 200208 | info@tuxis.nl > A terrible write performance may come from Linux mount options in fstab : There is sync / async for the NFS connection : I was set sync : A file requiring 30 ( thirty ) SECONDs to write become 30 MINUTEs to write . After working to solve this problems by trying diffrerent parameter setting over many days , there only remained sync / async . When I selected async , writes turned to NORMAL . I do not know effect of compression ( my opinion is that it will not be "terrible" ) , but my suggestion is to check as a possible trouble point : sync / async in Linux computer ( in fstab or mount statement ) Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 17:08:05 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CDCAE26 for ; Thu, 13 Nov 2014 17:08:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E43D18BA for ; Thu, 13 Nov 2014 17:08:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sADH7xM6099275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 19:07:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sADH7xM6099275 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sADH7x0h099274; Thu, 13 Nov 2014 19:07:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Nov 2014 19:07:59 +0200 From: Konstantin Belousov To: Mike Gelfand Subject: Re: [BUG] Getting path to program binary sometimes fails Message-ID: <20141113170758.GY17068@kib.kiev.ua> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:08:05 -0000 On Thu, Nov 13, 2014 at 10:33:47AM +0000, Mike Gelfand wrote: > Hello, > > I?ve been advised (on #freebsd @FreeNode) to send a mail here with details. > > I?m observing a weird issue where process may not able to determine path to its own binary (and maybe other process binaries as well, thought I didn?t test that) under some [not yet clear to me] conditions. The code I use in production first tries to call sysctl(KERN_PROC_PATHNAME) and if that fails fallback to call readlink(/proc/curproc/file); at some point both calls fail with ENOENT. This happens on two FreeBSD 9 (vanilla 9.1-RELEASE and 9.2-RELEASE) machines, and never happens (or at least never happened in over two years) on FreeBSD 8 (vanilla 8.3-RELEASE-p3); all machines are amd64. I?ve been able to reduce the test case to a sample program [1] which I run using a sample script [2], and the error then happens when I?m building clang-devel from ports. I?ve also recorded a screencast [3]. > > Is this a know defect? Do you need any other information other than provided above to reproduce? > > [1] http://mikedld.com/f/selfpath/selfpath.c > [2] http://mikedld.com/f/selfpath/selfpath.sh > [3] http://mikedld.com/f/selfpath/selfpath.mov This is not a defect. The vnode->path translation uses namecache, which could be purged at any time. The behaviour is typical for most unix implementations. Linux and new Solaris have 'rigid' namecache, where name entry lifetime is the same as the vnode lifetime it is attached to. I am not aware of any useful consequences of such design, except vn_fullpath() working more reliable, but at the cost of increased memory usage. Another possible reason for failed translation is the replacement of the binary while it runs. There, rigid namecache does not help. Typically, less time was spent between exec() and vn_fullpath(), more the chances to get the path back. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 19:10:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C78117E for ; Thu, 13 Nov 2014 19:10:48 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D985E898 for ; Thu, 13 Nov 2014 19:10:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id sADJAlal060901 for ; Thu, 13 Nov 2014 19:10:47 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id sADJAlp4060900 for freebsd-hackers@freebsd.org; Thu, 13 Nov 2014 19:10:47 GMT (envelope-from bdrewery) Received: (qmail 91487 invoked from network); 13 Nov 2014 13:10:43 -0600 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 13 Nov 2014 13:10:43 -0600 Message-ID: <54650232.1070802@FreeBSD.org> Date: Thu, 13 Nov 2014 13:10:42 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sebastian Kuzminsky , "freebsd-hackers@freebsd.org" Subject: Re: 1 gig superpages References: In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Onm4TPbVkjOJeCF5AabrHtUT3eo8Bq65b" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:10:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Onm4TPbVkjOJeCF5AabrHtUT3eo8Bq65b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/10/2014 10:15 AM, Sebastian Kuzminsky wrote: > Hello hackers, I'm announcing the availability of a branch adding suppo= rt for 1 GB superpages to FreeBSD. >=20 > https://github.com/Seb-LineRate/freebsd/commits/seb/stable-10/1-gig-pag= es >=20 > The branch is based on work done by Line Rate Systems and F5 Networks, = and used in our LROS load-balancing product. >=20 > Our product is based on FreeBSD 9.1; the branch I linked to above is ou= r 1 gig page support rebased onto stable/10. I probably messed something= up in the rebase, as lots of things changed both in pmap and vm since 9.= 1. There are also a handful of commits that i haven't gotten to yet, but= they are less consequential - just performance improvements to the buddy= allocator. I hope to push those over the next few days. >=20 > It should be relatively easy to rebase the branch onto Current. >=20 >=20 > This is a work in progress, and I would appreciate feedback and comment= s. https://www.freebsd.org/cgi/man.cgi?query=3Dstyle&sektion=3D9 Please follow our style guidelines. You may want to wait to clean that up until there is more technical feedback though. --=20 Regards, Bryan Drewery --Onm4TPbVkjOJeCF5AabrHtUT3eo8Bq65b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUZQIzAAoJEDXXcbtuRpfPzJkIAMYsjgtSWbOxyydBIseOHLh8 TIyXDUbf10alIjuHLcfVaf2JB3QAqIVwqQxmQ9dyUgoxl1adUvX05I6xsPwwq3p3 YlV1j1Q7nEoBFuQ5h519YXLmHWcc6W4fUWAXisWFpPNYobU3Wk8B/uw+e4BzrfQx Dkf0wV8ynWEl4u1wFo85OQaRqqkkoAyl6XJoZN2jtzuzmXxXXHwVyw7GWLP3FQ5x rFDrQXpRcsb5h8ZrfUD4rkjidDt6YXdbgACPS37F26YXkOkkhh0dCG/it6vA0FMz NTP9zEb1XgO8CmcEuonMgwDP8IOodkuDccFWQ0gK+xspWPBMAXDTTnTu5lNYJBM= =ZHxH -----END PGP SIGNATURE----- --Onm4TPbVkjOJeCF5AabrHtUT3eo8Bq65b-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 19:17:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97C6A511 for ; Thu, 13 Nov 2014 19:17:24 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 68A68909 for ; Thu, 13 Nov 2014 19:17:24 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sADJHMRE046623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2014 11:17:22 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sADJHL1J046622; Thu, 13 Nov 2014 11:17:21 -0800 (PST) (envelope-from jmg) Date: Thu, 13 Nov 2014 11:17:21 -0800 From: John-Mark Gurney To: Mehmet Erol Sanliturk Subject: Re: Slow nfsd write performance, tweaks needed Message-ID: <20141113191721.GJ24601@funkthat.com> Mail-Followup-To: Mehmet Erol Sanliturk , Rick Macklem , FreeBSD Hackers , Mark Schouten References: <2826701214-10966@kerio.tuxis.nl> <1841043385.12560911.1415883615679.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 13 Nov 2014 11:17:23 -0800 (PST) Cc: FreeBSD Hackers , Rick Macklem , Mark Schouten X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:17:24 -0000 Mehmet Erol Sanliturk wrote this message on Thu, Nov 13, 2014 at 05:14 -0800: > On Thu, Nov 13, 2014 at 5:00 AM, Rick Macklem wrote: > > > Mark Schouten wrote: > > > Hi, > > > > > > > > > I am in the process of switching from a ZFS On Linux-based NFS-server > > > to a FreeBSD-based NFS-server. The FreeBSD implementation of ZFS is > > > way superiour over ZoL, and the box serves as storage for a > > > virtualizationplatform, so stability is welcome. :) > > > > > > > > > The box is stable, but performs terribly. Surely, I'm doing something > > > wrong, but I would like some tips and tricks to speed things up. > > > > > > > > > > > > > > > Here's my setup: > > > CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz (HyperThreading is > > > enabled) > > > RAM: 64GB > > > NIC: 2x igb in lagg0 (loadbalancing) > > Oops, I didn't see this before my last post. igb had problems with > > the 64K TSO issue and I'd try to get rid of lagg as well. > > (You might be much better off just using a single net interface > > without lagg.) > > > > Again, good luck with it, rick > > > > > Disks: > > > > > > export1 1.81T 914G 942G 49% 1.00x ONLINE - > > > mirror 928G 457G 471G - > > > da0 - - - - > > > da1 - - - - > > > mirror 928G 457G 471G - > > > da2 - - - - > > > da3 - - - - > > > mirror 9.94G 173M 9.77G - > > > da4p1 - - - - > > > da5p1 - - - - > > > cache - - - - - - > > > da4p2 223G 223G 8M - > > > da5p2 223G 223G 8M - > > > > > > > > > da0-3 are 1TB WDs > > > da4-5 are 240GB Samsung SSD 840s > > > > > > > > > Here's (related) info from rc.conf. > > > > > > nfs_server_enable="YES" > > > nfs_server_flags="-u -t -n 128" > > > rpcbind_enable="YES" > > > mountd_enable="YES" > > > rpc_lockd_enable="YES" > > > rpc_statd_enable="YES" > > > > > > > > > > > > > > > I have compression enabled on all the ZFS-filesystems, and > > > jumboframes are enabled on the nics. > > > > > > > > > As soon as one of the (Linux) clients start to do some IO, NFS > > > responsetimes go up bigtime (yesterday up to 13 seconds), while the > > > hardware is pretty much idle, I must be doing something very wrong. > > > I'm mostly a Linux-guy, so any hit with a FreeBSD cluebat is > > > appreciated. > > > > > > > > > Regards, > > > > > > > > > -- > > > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > > > Mark Schouten | Tuxis Internet Engineering > > > KvK: 61527076 | http://www.tuxis.nl/ > > > T: 0318 200208 | info@tuxis.nl > > > > > > A terrible write performance may come from Linux mount options in fstab : > > > There is sync / async for the NFS connection : > > I was set sync : A file requiring 30 ( thirty ) SECONDs to write become 30 > MINUTEs to write . > After working to solve this problems by trying diffrerent parameter setting > over many days , there only remained sync / async . > When I selected async , writes turned to NORMAL . > > I do not know effect of compression ( my opinion is that it will not be > "terrible" ) , but my suggestion is to check as a possible trouble point : > > sync / async in Linux computer ( in fstab or mount statement ) This sounds like you might want a ZIL added to your server... Make sure you use an SSD.. Since you're using an NFS server, it cannot reply success to an operation till it is committed to stable storage which it sounds like is slow... With a ZIL on an SSD, it can more quickly commit the NFS request to stable storage and return success much quicker... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 19:23:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19E80731; Thu, 13 Nov 2014 19:23:43 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E445F9E1; Thu, 13 Nov 2014 19:23:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DB005B94F; Thu, 13 Nov 2014 14:23:41 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: DTrace: stack() does not print kernel module functions for i386 Date: Thu, 13 Nov 2014 13:36:12 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> In-Reply-To: <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201411131336.12334.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Nov 2014 14:23:41 -0500 (EST) Cc: Konstantin Belousov , avg@freebsd.org, Shrikanth Kamath , freebsd-dtrace@freebsd.org, Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:23:43 -0000 On Sunday, November 09, 2014 1:57:19 pm Rui Paulo wrote: > On Nov 9, 2014, at 01:36, Konstantin Belousov wrote: > > > > On Sat, Nov 08, 2014 at 02:06:39PM -0800, Shrikanth Kamath wrote: > >> I verified this on a FreeBSD 10.0 STABLE, the stack() feature does not > >> appear to print functions from kernel modules. I believe there is a > >> glitch in libdtrace in the function "dt_module_update" > >> (cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c). > >> > >> The section header address computation which is currently being done > >> in the function dt_module_update for elf type ET_REL, a similar > >> computation needs to be done for the ET_DYN maybe. I lack background > >> on the elf types but for experiment sakes I changed the line > >> > >> @@ -948,7 +948,7 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_fil > >> #if defined(__FreeBSD__) > >> mapbase = (uintptr_t)k_stat->address; > >> gelf_getehdr(dmp->dm_elf, &ehdr); > >> - is_elf_obj = (ehdr.e_type == ET_REL); > >> + is_elf_obj = (ehdr.e_type == ET_REL) || (ehdr.e_type == ET_DYN); > >> if (is_elf_obj) { > >> dmp->dm_sec_offsets = > >> malloc(ehdr.e_shnum * sizeof(*dmp->dm_sec_offsets)); > >> > >> So from a previous run where I was running a dtrace one liner > >> %dtrace -n 'fbt:hwpmc:: { stack(); }' > >> The output without the above change shows a sample as > >> > >> 0 50825 pmc_find_process_descriptor:entry > >> 0xc3c35bf5 <-- Address > >> not matched to symbol > >> kernel`syscall+0x48b > >> kernel`0xc0fd2121 > >> > >> whereas with the above nit change to include ET_DYN for section offset > >> adjustment I get the complete stack trace as > >> > >> 0 50825 pmc_find_process_descriptor:entry > >> hwpmc.ko`pmc_hook_handler+0x6a5 <--address matched to symbol > >> kernel`syscall+0x48b > >> kernel`0xc0fd2121 > >> > >> I believe without the correct section offset adjustment the following > >> check in the function dtrace_lookup_by_addr fails to match the address > >> to the correct symbol > >> > >> if (addr - dmp->dm_text_va < dmp->dm_text_size || > >> addr - dmp->dm_data_va < dmp->dm_data_size || > >> addr - dmp->dm_bss_va < dmp->dm_bss_size) > >> > >> because dml->dm_text_va was not setup correctly in dt_module_update. > >> > >> Can somebody help clarify this? > >> > >> Reference: commit revision 210425. > > > > I have no idea about DTrace guts, but can add one note you might find > > useful. > > > > From the backtace above I can conclude that your platform is i386. > > A difference between i386 and amd64 is that i386 modules are dso's > > (ET_DYN), while on amd64 modules are only linked to object files > > (ET_REL). The original author of the code probably tested on amd64. > > > > You may want to special case amd64 by #ifdef, and use ET_DYN on other > > arches. > > I agree with your analysis. I think this patch should go in with the #ifdef __amd64__ for ET_REL. > Why have the #ifdef? In theory other platforms besides amd64 could use sys/kern/link_elf_obj.c. It doesn't hurt to just let the code always accept both ET_DYN and ET_REL does it? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 13 20:30:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B8796EE; Thu, 13 Nov 2014 20:30:52 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6904FB; Thu, 13 Nov 2014 20:30:51 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id l13so386778iga.14 for ; Thu, 13 Nov 2014 12:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EYYrKEUZZxKeJpOyX7WRnVg3E+AF5z2QG2xMyV8AuHw=; b=lR9TrNwGL+gR69DoO/oPioVjg/1gE4yDi0PX4hJGr8IDIIPMeQCCp3jSWeOXBj5La/ 60XO0RktZh/Bg69j7aL+iKlREd22glEPJCirRo9VFtOQbV5e5wzoBYa7GxtxBCpGl9fx ut6bZQX0p0JgJkQQE3n6KOoKz+09Nff1Q6lokBCdrEjNmKdLh8KBZbz1+rrbmcFvUUIg 5a3PpOSCcbp7GIOHwRdAQN7N5ZEwNGSk+oHowFWDg2VTfIVHKicmqhqHf8pHgQrTxEXN b9qLn2jXyvwtDnGd2pWDLHp7A6Scch6uE56WMm2Uf6N9RXTd9vgrnI/9Ml4DXEYl0DMo E8kw== MIME-Version: 1.0 X-Received: by 10.50.66.227 with SMTP id i3mr1238079igt.25.1415910651227; Thu, 13 Nov 2014 12:30:51 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.43.96.202 with HTTP; Thu, 13 Nov 2014 12:30:51 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Nov 2014 15:30:51 -0500 X-Google-Sender-Auth: 06wtB3AUom5IvkrEtwySWyqkan0 Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: J David To: Ilya Bakulin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-net@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:30:52 -0000 On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: > Of course it was interesting what does the upstream PF do (@ OpenBSD). Seems > they have made the decision to > leave the task of recalculating the checksums for outgoing packets to > ip[6]_output, because currently > the code there overwrites the checksum anyway. > This seems a correct way to me. pf should not longer do any checksum updates > in inbound and outbound path. Is there any chance this change would help with bug 179392 as well? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 Or is that a separate issue? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 01:15:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21BC6E0B; Fri, 14 Nov 2014 01:15:20 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B429133A; Fri, 14 Nov 2014 01:15:19 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id sAE16gRe090216; Fri, 14 Nov 2014 01:06:43 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id sAE16gdp090215; Fri, 14 Nov 2014 01:06:42 GMT (envelope-from wkoszek) Date: Fri, 14 Nov 2014 01:06:42 +0000 From: "Wojciech A. Koszek" To: Alan Somers Subject: Re: FreeBSD + Google Code-In 2014 = we need ideas. Message-ID: <20141114010642.GB89106@FreeBSD.org> References: <20141110035915.GA50986@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,URIBL_DBL_REDIR autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Fri, 14 Nov 2014 01:06:49 +0000 (UTC) Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 01:15:20 -0000 On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: > On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek wrote: > > Hello, BTW, FYI: We didn't make it this year. Judging by the GSoC 2014 Reunion, there is a lot of seasoned Orgs which treat GCIN very seriously, so I think if we plan to participate, it'll be a lot of effort to compete with them Anyway: thanks for the tasks which were submitted. I will put them in Wiki for the reference, Wojciech > > > > This year we'd like to participate in the Google Code-In 2014. This is > > Google Summer of Code, but for younger people: age range is 13--17. If > > you're one of them, we highly encourage you to apply! > > > > ***This year coding tasks are possible, so feel free to add those*** > > > > To submit idea which you'd like to see done in GCI, visit: > > > > http://bit.ly/FreeBSD_GCIN2014 > > > > Regardless of who you are, please use the form to submit ideas. Don't add > > stuff via Wiki, since this year we'll do direct import of all ideas from > > Google Forms. > > > > To see tasks from previous year that are yet to be copied to Google Forms: > > > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > > > Thanks to GCI in the previous years, we gained one more FreeBSD developer. > > We'd like to partcipate this year too. We need: > > > > 1) ideas. > > > How about converting various utility functions to use libxo? I think > that's within the grasp of a high-schooler. > > > > > > 2) mentors > > > > 3) participants. > > > > Just like in previous years we'll decide whether we're ready. Deadlines: > > > > --- > > November 12, 2014 - The 10-12 Mentoring organizations are announced for > > Google Code-in 2014 and the orgs can start entering their tasks into the > > Google system (the tasks will not be viewable to students until the contest > > opens on Dec 1). > > December 1, 2014 17:00 UTC - Google Code-in 2014 contest opens for students > > January 19, 2015 17:00 UTC - Google Code-in 2014 student work ends > > --- > > > > MORE INFO: > > > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > > [1] gci-mentors@googlegroups.com > > [2] https://developers.google.com/open-source/gci/resources/mentor-and-orgadmin-info > > > > -- > > Wojciech A. Koszek > > wkoszek@FreeBSD.czest.pl > > http://FreeBSD.czest.pl/~wkoszek/ > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 01:40:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68F4E376; Fri, 14 Nov 2014 01:40:02 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDBBB79F; Fri, 14 Nov 2014 01:40:01 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id b13so18213570wgh.26 for ; Thu, 13 Nov 2014 17:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=ERVdAnQ2p+YzJIOZIUCzbLP3BM9C0Y+IFUkZBk+/oCM=; b=Ihh5R4SDOWklentsE0YMd0nGwMzNHAZaouPXrhUN0WCH0u1NKtjIbtqW7eYuq8xXUv UxIa1dhxqyk1GCeH7Otx5AOPSNNrnCv2X1+BAXl4IsRxr40hFnsWTRBYxJhiIQkDaFpw wL51wuWYsLpXGddrcmhrtqRKRSeWFxtCxFKSXCkvTHtXTAV5vfQ3tJnnzG3zaINCvmZY 1QzOGyUtnTP/+rM6wDGoNTwIwfgwYFgKInWu2i3pSQm3FXh40Yqg8/9oeHJpyataT+um rcrn/B3HVwmfb3vrbLFCHWvR6yxhMwci94gL1vw0D5RQU6gb7BZCsEjH2hePoAMW+y0k pHJA== MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr9485384wjb.78.1415929200339; Thu, 13 Nov 2014 17:40:00 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Thu, 13 Nov 2014 17:40:00 -0800 (PST) Date: Thu, 13 Nov 2014 17:40:00 -0800 X-Google-Sender-Auth: nKWFoKJddQ3JUgIt_68XbOAJ7xc Message-ID: Subject: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Luigi Rizzo To: "Wojciech A. Koszek" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 01:40:02 -0000 On Thu, Nov 13, 2014 at 5:06 PM, Wojciech A. Koszek wrote: > On Mon, Nov 10, 2014 at 01:56:27PM -0700, Alan Somers wrote: > > On Sun, Nov 9, 2014 at 8:59 PM, Wojciech A. Koszek > wrote: > > > Hello, > > BTW, FYI: > > We didn't make it this year. > > Judging by the GSoC 2014 Reunion, there is a lot of seasoned Orgs which > treat GCIN very seriously, so I think if we plan to participate, it'll be= a > lot of effort to compete with them > > Anyway: thanks for the tasks which were submitted. I will put them in Wik= i > for the reference, > =E2=80=8Bhi, i meant to send this email before but given the outcome this seems a good time to prepare for next year. I have been looking at tasks to submit (especially coding, but not just those) and looking at other organisations who participated in past years, i believe that FreeBSD (with its C- and kernel- centric environment) is a poor match for code-in, specifically due to the young age and predictable lack of expertise of most of the participants, and the small size of the tasks. In my view, most of the documentation tasks listed in the wiki https://wiki.freebsd.org/GoogleCodeIn/2014Tasks are not approachable by students -- they require experience and knowledge of compilers, subsystems and development techniques that are unlikely to exist for teenagers. When it comes to programming tasks, again the list has entries simply beyond the ability of the students. First three tasks: "static analysis for kernel locking", "static analysis of kernel conventions", "profile libc++". These are important tasks, but they just do not belong here. As a rule of thumb i would say that anything that is in the list should not take more than 2-3 hours/half a day to an experienced developer, be accompanied by a detailed description on what to do and how, and by a commitment from the mentor to review it. Also, if we want to suggest some coding task, it is important that we can give students a preloaded OS image with all the tools and repos they may need for their work, otherwise they end up spending a lot of time setting up the environment and possibly making mistakes in the process that prevent a correct completion of the work. Sure we ship with compilers and make, but we miss svn/git, an embedded snapshot of source and ports tree, and now that we can, also a bhyve or qemu example to help them testing kernels. Finally, we should shift the approach from "something we need" to "something can be a useful exercise for the students" even if it replicates features that already exist in the OS. That might perhaps lead to smaller, better and easier to define tasks with a better chance to be completed. Lacking any better idea (which I don't have because as i said i think FreeBSD just is not a good match for this competition), we could take some specific bug reports, and provide details and hints for solutions. But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. =E2=80=8Bcheers luigi =E2=80=8B > > Wojciech > > > > > > > This year we'd like to participate in the Google Code-In 2014. This i= s > > > Google Summer of Code, but for younger people: age range is 13--17. I= f > > > you're one of them, we highly encourage you to apply! > > > > > > ***This year coding tasks are possible, so feel free to add those*** > > > > > > To submit idea which you'd like to see done in GCI, visit: > > > > > > http://bit.ly/FreeBSD_GCIN2014 > > > > > > Regardless of who you are, please use the form to submit ideas. Don'= t > add > > > stuff via Wiki, since this year we'll do direct import of all ideas > from > > > Google Forms. > > > > > > To see tasks from previous year that are yet to be copied to Google > Forms: > > > > > > https://wiki.freebsd.org/GoogleCodeIn/2014Tasks > > > > > > Thanks to GCI in the previous years, we gained one more FreeBSD > developer. > > > We'd like to partcipate this year too. We need: > > > > > > 1) ideas. > > > > > > How about converting various utility functions to use libxo? I think > > that's within the grasp of a high-schooler. > > > > > > > > > > 2) mentors > > > > > > 3) participants. > > > > > > Just like in previous years we'll decide whether we're ready. > Deadlines: > > > > > > --- > > > November 12, 2014 - The 10-12 Mentoring organizations are > announced for > > > Google Code-in 2014 and the orgs can start entering their > tasks into the > > > Google system (the tasks will not be viewable to students > until the contest > > > opens on Dec 1). > > > December 1, 2014 17:00 UTC - Google Code-in 2014 contest open= s > for students > > > January 19, 2015 17:00 UTC - Google Code-in 2014 student work > ends > > > --- > > > > > > MORE INFO: > > > > > > [0] http://www.google-melange.com/gci/homepage/google/gci2014 > > > [1] gci-mentors@googlegroups.com > > > [2] > https://developers.google.com/open-source/gci/resources/mentor-and-orgadm= in-info > > > > > > -- > > > Wojciech A. Koszek > > > wkoszek@FreeBSD.czest.pl > > > http://FreeBSD.czest.pl/~wkoszek/ > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > -- > Wojciech A. Koszek > wkoszek@FreeBSD.czest.pl > http://FreeBSD.czest.pl/~wkoszek/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 03:49:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B9C8D92; Fri, 14 Nov 2014 03:49:44 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2EEB616; Fri, 14 Nov 2014 03:49:43 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NF000FP9FYFBW20@st11p02mm-asmtp001.mac.com>; Fri, 14 Nov 2014 03:49:30 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-14_01:2014-11-14,2014-11-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411140032 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: DTrace: stack() does not print kernel module functions for i386 From: Rui Paulo In-reply-to: <201411131336.12334.jhb@freebsd.org> Date: Thu, 13 Nov 2014 19:49:27 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20141109093632.GV53947@kib.kiev.ua> <9011F920-3092-4E61-9CDC-68FD9092BB7D@me.com> <201411131336.12334.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1990.1) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, Shrikanth Kamath , avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 03:49:44 -0000 On Nov 13, 2014, at 10:36, John Baldwin wrote: > Why have the #ifdef? In theory other platforms besides amd64 could = use > sys/kern/link_elf_obj.c. It doesn't hurt to just let the code always = accept > both ET_DYN and ET_REL does it? No, it doesn't hurt. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 03:55:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A552EBC; Fri, 14 Nov 2014 03:55:31 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D100A6C9; Fri, 14 Nov 2014 03:55:30 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NF0002AIG850V70@st11p02mm-asmtp002.mac.com>; Fri, 14 Nov 2014 03:55:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-14_01:2014-11-14,2014-11-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411140033 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Rui Paulo In-reply-to: Date: Thu, 13 Nov 2014 19:55:16 -0800 Content-transfer-encoding: quoted-printable Message-id: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> References: To: Luigi Rizzo X-Mailer: Apple Mail (2.1990.1) Cc: "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , "Wojciech A. Koszek" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 03:55:31 -0000 On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > But please nuke the current list -- it is completely inadequate > for the code-in candidates and misleading for whoever wants to > suggest new tasks. Again i am not saying that the projects > suggested there are not important, just belong somewhere else > e.g. gsoc. I refrained from voicing my opinion while the call for help was going = on, but I completely agree that the target age of this Google initiative = is inadequate to FreeBSD. The target population is 13 years to 17 years = old and I cannot even imagine a 13 year old knowing what FreeBSD is. I'm not sure we should participate in Code In ever again and perhaps we = should focus our efforts on Summer of Code only. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 08:17:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAE5B8EC; Fri, 14 Nov 2014 08:17:50 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85C56111; Fri, 14 Nov 2014 08:17:50 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ey11so235425pad.24 for ; Fri, 14 Nov 2014 00:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ze6ZEe9QWhS4n4LP42H1dgc2Zhq5Uv/mRTV2Uo23h8U=; b=zT0xhxOkl9CKxrCXTEKqOjx0FlQWmrn3osV4pU7gTkjXgN7uvfa5BuPVvatOt6L4Lc ApvO0p9PrNTqg4ASOZULKUGQqFpZtj1eZvJrtsFtc37fsKahfOCzw3drVvt4EP/Z0z0v bouWPhcd0Km9IU7/batqTyadgDma9YsgYarf+aUl/cpGLE2k4YfUdM0UMKRXVaji9Zhg 6BRTac9SPDmz0NdSPQL28OqJU9/sGRSEjdoFk3UCohJ/3cXTd9RKjsRGRzhWuaojygtf bjji3ymgZeZPyYgRKNVzGL1+TrFpuDuSSmWaXVMxIQfzcw5R1udmyDwYNtb7C5pl+u80 59cA== MIME-Version: 1.0 X-Received: by 10.70.53.102 with SMTP id a6mr8544073pdp.70.1415953070139; Fri, 14 Nov 2014 00:17:50 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.73.2 with HTTP; Fri, 14 Nov 2014 00:17:50 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Nov 2014 09:17:50 +0100 X-Google-Sender-Auth: guUO7D1MGPk71ej7uaY04b7D5CY Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: J David Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Ilya Bakulin , "freebsd-pf@freebsd.org" , freebsd-net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 08:17:50 -0000 Yes confirmed it will solve that issue as well. On Thu, Nov 13, 2014 at 9:30 PM, J David wrote: > On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: > > Of course it was interesting what does the upstream PF do (@ OpenBSD). > Seems > > they have made the decision to > > leave the task of recalculating the checksums for outgoing packets to > > ip[6]_output, because currently > > the code there overwrites the checksum anyway. > > This seems a correct way to me. pf should not longer do any checksum > updates > > in inbound and outbound path. > > Is there any chance this change would help with bug 179392 as well? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 > > Or is that a separate issue? > > Thanks! > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 09:33:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAE5493D for ; Fri, 14 Nov 2014 09:33:48 +0000 (UTC) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 602B6AE4 for ; Fri, 14 Nov 2014 09:33:47 +0000 (UTC) Received: from straylight.m.ringlet.net (unknown [46.233.30.128]) by nimbus.fccf.net (Postfix) with ESMTPSA id 73A6E4A3 for ; Fri, 14 Nov 2014 11:27:27 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 2540176 by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Fri, 14 Nov 2014 11:27:26 +0200 Date: Fri, 14 Nov 2014 11:27:26 +0200 From: Peter Pentchev To: Rui Paulo Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) Message-ID: <20141114092726.GH3196@straylight.m.ringlet.net> Mail-Followup-To: Rui Paulo , Luigi Rizzo , "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , "Wojciech A. Koszek" , Alan Somers References: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a7XSrSxqzVsaECgU" Content-Disposition: inline In-Reply-To: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Wojciech A. Koszek" , "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , Luigi Rizzo , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 09:33:49 -0000 --a7XSrSxqzVsaECgU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: > On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > > But please nuke the current list -- it is completely inadequate > > for the code-in candidates and misleading for whoever wants to > > suggest new tasks. Again i am not saying that the projects > > suggested there are not important, just belong somewhere else > > e.g. gsoc. >=20 > I refrained from voicing my opinion while the call for help was going > on, but I completely agree that the target age of this Google initiative > is inadequate to FreeBSD. The target population is 13 years to 17 years > old and I cannot even imagine a 13 year old knowing what FreeBSD is. =2E..and yet there was pat@ becoming a ports committer at the age of 16 and chris@ becoming a docs committer at the age of 14 :) I think hmp@, alepulver@, issyl0@ and jmallett@ were pretty young when they joined, too. Just an observation, I know that one or two isolated cases do not prove a point :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --a7XSrSxqzVsaECgU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUZcr5AAoJEGUe77AlJ98TzGkP/RVzKKGRJIIhSAGOUSwTvF+g VDMO9/8G5eAgob5njG3LDyYhZ8+ni2kMfLqsQZArz8JNocAEF8I2M6UmahQdBDFg X6Wqiyp4rOaz4NHofDgibkRMlBzgh9/YhqG2oyL090t2MlsP3t27jdkJUoKN2e6C zCopo250Pn46ZsS3cSDu1vD3MTZMucrUzSbbo9aZQ4nNTQ5BtL7RQCtJCCQGosy1 W2hJqkIIRaRC3ruCN2dbuK+dBkZWgBJBzdTQd50FTSUzNAXJikNADoTxxtMYn5d9 H5pfMPzOPZWxmOAP1DG9orB90m5Rc/FP4WHUF5KNap1RYgCX0hjW/OR33+LBzznY 3oU61XJinbfI8E7sh4eJB+ThHahHBYnBvvhvo8FvnemsTGD26VPV+z89vcNi3dR9 cfMa6V3J7BZmDX0asvMbIQ5Vb46l/jC/vG4i7kMC3eWPQWeBY30/jhJatdcoqCH+ b5FsnjuH19z8bSK87V1WT1FhPd1PmFMjmIiaciKxffB3H5VFIBG1L/2vRAEq6LUo 4sPn8VvUNToWBva0Az1fLwTfZ0LsSIr/uMUWkT0eLLJH+y+spJC426t0BrsEnD0L qHYCuGW02JvYDN/9KzJvdBdOwl3Can7vLjr9i1AiDBnJ/JQdscHjAaeRbtrgPCrW AqkswiV6mRP2JWCK5K15 =3R3n -----END PGP SIGNATURE----- --a7XSrSxqzVsaECgU-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 10:23:12 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A63B5969 for ; Fri, 14 Nov 2014 10:23:12 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4879FFDD for ; Fri, 14 Nov 2014 10:23:12 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAEAN6Hd036666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2014 12:23:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAEAN6Hd036666 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAEAN6u0036665; Fri, 14 Nov 2014 12:23:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Nov 2014 12:23:06 +0200 From: Konstantin Belousov To: Mike Gelfand Subject: Re: [BUG] Getting path to program binary sometimes fails Message-ID: <20141114102306.GE17068@kib.kiev.ua> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 10:23:12 -0000 On Fri, Nov 14, 2014 at 09:54:18AM +0000, Mike Gelfand wrote: > On Nov 13, 2014, at 8:07 PM, Konstantin Belousov wrote: > > > This is not a defect. The vnode->path translation uses namecache, which > > could be purged at any time. The behaviour is typical for most unix > > implementations. Linux and new Solaris have 'rigid' namecache, where > > name entry lifetime is the same as the vnode lifetime it is attached to. > > I am not aware of any useful consequences of such design, except > > vn_fullpath() working more reliable, but at the cost of increased > > memory usage. > > The man page for sysctl(3) states that ?Unless explicitly noted > below, sysctl() returns a consistent snapshot of the data requested? > (surely we don?t expect half the path being returned; I?m just > trying to read thoroughly). Later on there are no special notes on > {CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME}; at least no notes on the > unstable behavior being observed, and no funny details of internal > implementation you describe. ERRORS section only describes ENOENT > condition as ?The name array specifies a value that is unknown,? which > certainly is not the case here. > > Since you?re saying that current behavior is not a defect, maybe > documentation is wrong (incomplete, misleading) then? I will readily > accept the ?not a defect? explanation, but only if one wouldn?t have > to ask you every time this oddity is met. If this is the expected Provide the documentation patch. > error condition, what should I do to get the path reliably? Should I > retry (and how many times)? You?re saying cache is being purged; does > it mean that when I ask for path then cache is populated again? Does > it guarantee then that I?ll be able to get the path on next call? > Could you guarantee that I?ll be able to get the path at all if I fail > two or more times? Should I rely on ENOENT specifically when retrying? After the path resolution failed, it can only succeed later if the cache is populated again. Cache cannot be populated by the vnode->path request, just think where to get the data ? The cache is populated when lookup is performed, so if nothing accessed the file by name between your two calls, second translation fails as well. > > It would also be nice if you could tell whether anything had possibly > changed between 8 and 9 releases that could lead to this behavior. As > I said before, same code works on FreeBSD 8 with no errors for more > than two years. Moreover, I didn?t previously mention that but 8 and > 9 systems which I?m currently testing on are installed on completely > identical hardware. Namecache behaves mostly the same in 8/9/10/HEAD. The failure of vnode->path resolution due to purged cache is expected. There are in fact some improvements, like relibably resolving pathes for directories (not for the regular files) and for some special filesystems like devfs or procfs. I do not remember exact point where that was added, in 8 or 9 lifetime. > > > Another possible reason for failed translation is the replacement of > > the binary while it runs. There, rigid namecache does not help. > > Not the case here. > > Kind regards, Mike From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 10:34:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1F2EC0B; Fri, 14 Nov 2014 10:34:53 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9D74312A; Fri, 14 Nov 2014 10:34:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com AEC4E75918 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415961291; bh=CvZtRqwKdnunq6RdTxnUtVo2X0hUlxmaO4TuhJTgee8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GL2gScTGZ4laPADEyB4Q+42PfeET7vuONMay1nI7isYwEAiNZNMfCiZCFIL9es3Gl 0ygjGOLCQOtK0uOBBZyrylvNLSDw67e9c6aZAjLYLTMhuPtdY9X5cylxm4xz7ry4ur DsOosdJ2ev7wasKjT0PGcFEZoPsysbXKgeB5bE5U= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 14 Nov 2014 11:34:51 +0100 From: Ilya Bakulin To: =?UTF-8?Q?Ermal_Lu=C3=A7i?= Subject: Re: Checksumming outgoing packets in PF vs in =?UTF-8?Q?ip=5B=36=5D=5Foutput?= Organization: Deglitch Networks In-Reply-To: References: Message-ID: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> X-Sender: ilya@bakulin.de Cc: freebsd-hackers@freebsd.org, freebsd-net , J David , owner-freebsd-net@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 10:34:54 -0000 Hi all, actually with _my_ checksumming patch the rdr-to is broken completely :-( So I'm waiting for Ermal to send an updated version of his patch that may really solve the problem! On 2014-11-14 09:17, Ermal Luçi wrote: > Yes confirmed it will solve that issue as well. > > On Thu, Nov 13, 2014 at 9:30 PM, J David > wrote: > >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: >> > Of course it was interesting what does the upstream PF do (@ OpenBSD). >> Seems >> > they have made the decision to >> > leave the task of recalculating the checksums for outgoing packets to >> > ip[6]_output, because currently >> > the code there overwrites the checksum anyway. >> > This seems a correct way to me. pf should not longer do any checksum >> updates >> > in inbound and outbound path. >> >> Is there any chance this change would help with bug 179392 as well? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 >> >> Or is that a separate issue? >> >> Thanks! >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 11:38:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6339BAC4 for ; Fri, 14 Nov 2014 11:38:28 +0000 (UTC) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BC81942 for ; Fri, 14 Nov 2014 11:38:27 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id l6so12664787qcy.36 for ; Fri, 14 Nov 2014 03:38:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=un6M/jZg61JE1Rv3LFgN1u+cC6AJQJEoJqOivCN7Xv0=; b=W8H7TFacDGH7ezrLXvaDaAtLCrfJO4Aj5Isr5o5UlLBaHqwXDDex3VtHjhfvvDqL60 gd7vWVd72mHvs5oXNv/VMfvBqaBSlc7x3L8FzOZFbsnS1sNfMiXFdGLZn2nRUAZpssNP qrTESaNicW+ugj2kILv8LtpOfIhLL93GFyMPL3hKbC1XBog/FKD3p009pbDPooXF57/r +m81scZJfUBN1ItlySgezgAxfEf88crT09o+5Ud3dyf+C+Kzf0UqowggKu/PuliRKeW8 Ddssa8fn7rKHXD1BeZ4kegtRhtJXcmhWT95PBjI46CKnR0FrDpsOOOHlmrZhoSeSH2u1 yHyg== X-Gm-Message-State: ALoCoQnrEJCd0+s6TWwnVFe+GTDJf39xaerYn9HTfU10/Hf34akFdmivs7DH1+NOgCD/WCqCmEeN X-Received: by 10.140.40.239 with SMTP id x102mr10511565qgx.69.1415965105573; Fri, 14 Nov 2014 03:38:25 -0800 (PST) Received: from [192.168.2.20] (ool-4351fb93.dyn.optonline.net. [67.81.251.147]) by mx.google.com with ESMTPSA id q90sm26623687qgd.4.2014.11.14.03.38.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 03:38:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Mark Saad X-Mailer: iPhone Mail (12B411) In-Reply-To: <20141114092726.GH3196@straylight.m.ringlet.net> Date: Fri, 14 Nov 2014 06:38:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> <20141114092726.GH3196@straylight.m.ringlet.net> To: Peter Pentchev Cc: Alan Somers , Rui Paulo , "freebsd-hackers@freebsd.org" , "Wojciech A. Koszek" , FreeBSD CURRENT , Luigi Rizzo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 11:38:28 -0000 > On Nov 14, 2014, at 4:27 AM, Peter Pentchev wrote: >=20 >> On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: >>> On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: >>> But please nuke the current list -- it is completely inadequate >>> for the code-in candidates and misleading for whoever wants to >>> suggest new tasks. Again i am not saying that the projects >>> suggested there are not important, just belong somewhere else >>> e.g. gsoc. >>=20 I have a few ideas for younger and or less experienced google code in people= 1. Analyze the CD/USB install process .=20 Does the actual process match the guide and or general docs .=20 2. Analyze / comment on the automated install process "jumpstart ". Does the= guide and general docs match the actual process . 3. Test the virtual machine images as vagrant box images , and create vagran= t box images from the official vm images .=20 4. Create a script for the installer "bsd install" to use glabel to label gp= arts slices as /dev/label/$NAME=20 5. Test the ami images , again can the docs be improved are they accurate . The=20 Now let me preface the docs tasks , by no means am I saying that the docs te= am has made lots of mistakes and their work needs to be rechecked . The task= s are small enough that most high school aged people could grasp the issue, w= ith out any prior experience in BSD world . Rechecking the docs is always a g= ood idea .=20 They should allow the code in members to make some good contributions ; and m= aybe even some good improvements .=20 >> I refrained from voicing my opinion while the call for help was going >> on, but I completely agree that the target age of this Google initiative >> is inadequate to FreeBSD. The target population is 13 years to 17 years >> old and I cannot even imagine a 13 year old knowing what FreeBSD is. >=20 > ...and yet there was pat@ becoming a ports committer at the age of 16 > and chris@ becoming a docs committer at the age of 14 :) I think hmp@, > alepulver@, issyl0@ and jmallett@ were pretty young when they joined, > too. >=20 > Just an observation, I know that one or two isolated cases do not prove > a point :) >=20 > G'luck, > Peter >=20 > --=20 > Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 Mark saad | mark.saad@longcount.org=20= From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 11:57:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A58D71AF; Fri, 14 Nov 2014 11:57:20 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B50AAF7; Fri, 14 Nov 2014 11:57:20 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id r10so16610539pdi.30 for ; Fri, 14 Nov 2014 03:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Z5hSeA4uiIDAQTvbBSZV1BFvEAkIXKm57wtpl+scDa0=; b=DEgkEGMX52pKynf+QiY988IEnrLAHbOnUx8dIUYW5Y0gqqgj25J5N3v2nzYXd2aq2n 0UifkBYFmfAQxTUQV7kwff1i3dJXfJOrdbbhKypOkkFXXHzXKRoJEA/mD42wlqOv7AR4 7a8OG9G3XPzF2kyHk4ySx4h7ReQEcImOVd5iHiH09OdjIGLnqxiIrFgpTy+np6jSFast WFcvzTBbA/MG2C3Bcdz5tVCUPNTN8NydlawKJ7b7xQ9jQ9GSc9cAlSEFCOgQEZSUzK6J dZW1ya3hdJEl7j9wRotitlqvtSuAY2V3V8Ptd9wcouxLX0I2gkOF7c/VX3zEd0ly7b1H E74g== MIME-Version: 1.0 X-Received: by 10.68.68.240 with SMTP id z16mr9624677pbt.70.1415966240025; Fri, 14 Nov 2014 03:57:20 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.73.2 with HTTP; Fri, 14 Nov 2014 03:57:19 -0800 (PST) In-Reply-To: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> References: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> Date: Fri, 14 Nov 2014 12:57:19 +0100 X-Google-Sender-Auth: bHDfgzl280RyWYloSRkyZ4_5K3c Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Ilya Bakulin Content-Type: multipart/mixed; boundary=001a113817fcc0512c0507d054a5 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Freebsd hackers list , freebsd-net , J David , owner-freebsd-net@freebsd.org, "freebsd-pf@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 11:57:20 -0000 --001a113817fcc0512c0507d054a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is a direct patch. Give it a try. For the reply-to issues there is another patch complementary to this i will send. On Fri, Nov 14, 2014 at 11:34 AM, Ilya Bakulin wrote: > Hi all, > > actually with _my_ checksumming patch the rdr-to is broken completely :-( > So I'm waiting for Ermal to send an updated version of his patch that may > really solve the problem! > > > On 2014-11-14 09:17, Ermal Lu=C3=A7i wrote: > >> Yes confirmed it will solve that issue as well. >> >> On Thu, Nov 13, 2014 at 9:30 PM, J David wrote= : >> >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin wrote: >>> > Of course it was interesting what does the upstream PF do (@ OpenBSD)= . >>> Seems >>> > they have made the decision to >>> > leave the task of recalculating the checksums for outgoing packets to >>> > ip[6]_output, because currently >>> > the code there overwrites the checksum anyway. >>> > This seems a correct way to me. pf should not longer do any checksum >>> updates >>> > in inbound and outbound path. >>> >>> Is there any chance this change would help with bug 179392 as well? >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D179392 >>> >>> Or is that a separate issue? >>> >>> Thanks! >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> > --=20 Ermal --001a113817fcc0512c0507d054a5 Content-Type: application/octet-stream; name="pf_ipv6_checksum.patch" Content-Disposition: attachment; filename="pf_ipv6_checksum.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i2hhqx000 ZGlmZiAtLWdpdCBhL3N5cy9uZXRwZmlsL3BmL3BmX2lvY3RsLmMgYi9zeXMvbmV0cGZpbC9wZi9w Zl9pb2N0bC5jCmluZGV4IGRiYTU2NzQuLmNhN2Y4NTEgMTAwNjQ0Ci0tLSBhL3N5cy9uZXRwZmls L3BmL3BmX2lvY3RsLmMKKysrIGIvc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwuYwpAQCAtNzYsNiAr NzYsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8bmV0aW5ldC9pbi5oPgog I2luY2x1ZGUgPG5ldGluZXQvaXAuaD4KICNpbmNsdWRlIDxuZXRpbmV0L2lwX3Zhci5oPgorI2lu Y2x1ZGUgPG5ldGluZXQ2L2lwNl92YXIuaD4KICNpbmNsdWRlIDxuZXRpbmV0L2lwX2ljbXAuaD4K IAogI2lmZGVmIElORVQ2CkBAIC0zNjE5LDEyICszNjIwLDkgQEAgcGZfY2hlY2s2X291dCh2b2lk ICphcmcsIHN0cnVjdCBtYnVmICoqbSwgc3RydWN0IGlmbmV0ICppZnAsIGludCBkaXIsCiAJaW50 IGNoazsKIAogCS8qIFdlIG5lZWQgYSBwcm9wZXIgQ1NVTSBiZWZvcmUgd2Ugc3RhcnQgKHMuIE9w ZW5CU0QgaXBfb3V0cHV0KSAqLwotCWlmICgoKm0pLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NV TV9ERUxBWV9EQVRBKSB7Ci0jaWZkZWYgSU5FVAotCQkvKiBYWFgtQlogY29weSZwYXN0ZSBlcnJv ciBmcm9tIHIxMjYyNjE/ICovCi0JCWluX2RlbGF5ZWRfY2tzdW0oKm0pOwotI2VuZGlmCi0JCSgq bSktPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJj0gfkNTVU1fREVMQVlfREFUQTsKKwlpZiAoKCptKS0+ bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fREVMQVlfREFUQV9JUFY2KSB7CisJCWluNl9kZWxh eWVkX2Nrc3VtKCptLCAoKm0pLT5tX3BrdGhkci5sZW4gLSBzaXplb2Yoc3RydWN0IGlwNl9oZHIp LCBzaXplb2Yoc3RydWN0IGlwNl9oZHIpKTsKKwkJKCptKS0+bV9wa3RoZHIuY3N1bV9mbGFncyAm PSB+Q1NVTV9ERUxBWV9EQVRBX0lQVjY7CiAJfQogCUNVUlZORVRfU0VUKGlmcC0+aWZfdm5ldCk7 CiAJY2hrID0gcGZfdGVzdDYoUEZfT1VULCBpZnAsIG0sIGlucCk7Cg== --001a113817fcc0512c0507d054a5-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 12:06:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B15DB7B2; Fri, 14 Nov 2014 12:06:13 +0000 (UTC) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65FAEC1E; Fri, 14 Nov 2014 12:06:13 +0000 (UTC) Received: by mail-yk0-f178.google.com with SMTP id 20so922523yks.23 for ; Fri, 14 Nov 2014 04:06:12 -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=nRoS1orkEfpRzT81vwLXPDdkt+O7irQNL+9rYVOUUps=; b=QA0OYY8Ovn/9O8Uq2PKMefzAe+frT5rjXn/qNdRdHmslcD71sOoDT1xmFCbBRc2JtH Y/wFMPC0BhJ7fLl8WKkIP0fRXl46Zczox42PAXuUSBGZ8aiZp9gUBbcOO2HPs64xTH+R UwfGzrCMWgzevmNbwY7re4OVMbK3OROfYeK8jYStWl4Xb1Zb3hq5qbMbO0xt7mEDMMBT 5nc5znlw46KtD4AF/UWczYmdzw+70u6EooR6dfY0tLFEB/wErFypj6Khv++I3pxscfYd bVI+ZLYSWT2bKLGgyE0ugjpSB6v8jKoBRcqVNGnuxXhyfN+zLt0M3U15JFuNp71/F2v3 NxOQ== MIME-Version: 1.0 X-Received: by 10.236.2.170 with SMTP id 30mr9330901yhf.122.1415966772530; Fri, 14 Nov 2014 04:06:12 -0800 (PST) Received: by 10.170.84.133 with HTTP; Fri, 14 Nov 2014 04:06:12 -0800 (PST) In-Reply-To: References: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> <20141114092726.GH3196@straylight.m.ringlet.net> Date: Fri, 14 Nov 2014 04:06:12 -0800 Message-ID: Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) From: Mehmet Erol Sanliturk To: Mark Saad Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Alan Somers , Rui Paulo , "freebsd-hackers@freebsd.org" , "Wojciech A. Koszek" , FreeBSD CURRENT , Luigi Rizzo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 12:06:13 -0000 On Fri, Nov 14, 2014 at 3:38 AM, Mark Saad wrote: > > > > On Nov 14, 2014, at 4:27 AM, Peter Pentchev wrote: > > > >> On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: > >>> On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > >>> But please nuke the current list -- it is completely inadequate > >>> for the code-in candidates and misleading for whoever wants to > >>> suggest new tasks. Again i am not saying that the projects > >>> suggested there are not important, just belong somewhere else > >>> e.g. gsoc. > >> > > I have a few ideas for younger and or less experienced google code in > people > > 1. Analyze the CD/USB install process . > Does the actual process match the guide and or general docs . > > 2. Analyze / comment on the automated install process "jumpstart ". Does > the guide and general docs match the actual process . > > 3. Test the virtual machine images as vagrant box images , and create > vagrant box images from the official vm images . > > 4. Create a script for the installer "bsd install" to use glabel to label > gparts slices as /dev/label/$NAME > > 5. Test the ami images , again can the docs be improved are they accurate . > > The > > Now let me preface the docs tasks , by no means am I saying that the docs > team has made lots of mistakes and their work needs to be rechecked . The > tasks are small enough that most high school aged people could grasp the > issue, with out any prior experience in BSD world . Rechecking the docs is > always a good idea . > > They should allow the code in members to make some good contributions ; > and maybe even some good improvements . > > >> I refrained from voicing my opinion while the call for help was going > >> on, but I completely agree that the target age of this Google initiative > >> is inadequate to FreeBSD. The target population is 13 years to 17 years > >> old and I cannot even imagine a 13 year old knowing what FreeBSD is. > > > > ...and yet there was pat@ becoming a ports committer at the age of 16 > > and chris@ becoming a docs committer at the age of 14 :) I think hmp@, > > alepulver@, issyl0@ and jmallett@ were pretty young when they joined, > > too. > > > > Just an observation, I know that one or two isolated cases do not prove > > a point :) > > > > G'luck, > > Peter > > > > -- > > Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com > > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 > > Mark saad | mark.saad@longcount.org > One important program class for the less experienced people ( as users and programmers ) would be the following : (1) For the command line operating system programs , mostly it is necessary to give parameters on command line . For example : $ ifconfig displays the NIC information . To apply some operations , it is necessary to give parameters : $ ifconfig -... ... .... ... ... To give these parameters even by using man pages are very difficult even for the experienced users . Task : By using for selected OS programs , write a routine to the following : When a user enters only program name , display a form to get parameters for execution ( this requires some changes to programs doing operations just by giving its name by specifying a parameter for such cases ) in such a way that get parameters in an order by supplying form parts with respect to previously given parameter values , i.e. , do not present all of the items , let the user some values , and smash the user that such parameters are given incorrectly . Manual pages may be used , but sometimes it is necessary to read the source code of the program to isolate error cases and dependencies . (2) Some programs may use many parameters and every time giving them as command line parameters or by filling forms may not be a very convenient way . By using Expat libraries ( or any other suitable library ) , write a routine for a selected command line program to enter parameters from an XML file with the following structure : $ program_name @XML_parameters file_name Such a result may be obtained by using scripts for executing the programs with specific parameters , but using the above structure may be more convenient usage and they may be used in testing also more easily because some files may be output of other programs . (3) Many OS programs are given their outputs in an arbitrary text form . For automated tests , or input to other programs , these outputs are very difficult to use . For selected OS programs , give all of the output in XML ( or any other selected structured form ) .which they can be processed by using Expat library . To process these outputs , also write a routine by using Expat library to load it into a tree . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 12:34:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C6E7EAB; Fri, 14 Nov 2014 12:34:34 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE83EFD; Fri, 14 Nov 2014 12:34:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 3743A75918 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415968470; bh=07v+EQ6VSe0WWql2imxQcrebpY21wPv/AqBSYQZikXU=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=bx9zwWEQ1iyauD09xBLVU4mPAEUkrNDUKir+HMErpjP4JLEmmA7il4pb4NMjIX+5U jwZXmNQ/tmeqQRFEm7Dz8+Kiy99l23IkDzNQgvNsO6OtbRO9wR055nu7P9me4U+WHu uc47QURrHWXXpB3mNSpe7jI38N9xNEyIZUrCuMzc= In-Reply-To: References: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> MIME-Version: 1.0 Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: Ilya Bakulin Date: Fri, 14 Nov 2014 13:34:29 +0100 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Freebsd hackers list , freebsd-pf@freebsd.org, freebsd-net , J David , owner-freebsd-net@freebsd.org, ermal.luci@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 12:34:34 -0000 Hi Ermal, yes, this patch works for both #179392 and #172648. What do you need to merge this into -CURRENT and MFC to stable/9? On 2014-11-14 12:57, Ermal Luçi wrote: > Here is a direct patch. > Give it a try. > > For the reply-to issues there is another patch complementary to this i > will send. > > On Fri, Nov 14, 2014 at 11:34 AM, Ilya Bakulin > wrote: > >> Hi all, >> >> actually with _my_ checksumming patch the rdr-to is broken >> completely :-( >> So I'm waiting for Ermal to send an updated version of his patch >> that may really solve the problem! >> >> On 2014-11-14 09:17, Ermal Luçi wrote: >> Yes confirmed it will solve that issue as well. >> >> On Thu, Nov 13, 2014 at 9:30 PM, J David >> wrote: >> >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin >> wrote: >>> Of course it was interesting what does the upstream PF do (@ >> OpenBSD). >> Seems >>> they have made the decision to >>> leave the task of recalculating the checksums for outgoing >> packets to >>> ip[6]_output, because currently >>> the code there overwrites the checksum anyway. >>> This seems a correct way to me. pf should not longer do any >> checksum >> updates >>> in inbound and outbound path. >> >> Is there any chance this change would help with bug 179392 as well? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 [1] >> >> Or is that a separate issue? >> >> Thanks! >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net [2] >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > > -- > > Ermal > > Links: > ------ > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179392 > [2] http://lists.freebsd.org/mailman/listinfo/freebsd-net -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 13:08:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91B3B70E; Fri, 14 Nov 2014 13:08:35 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58C85243; Fri, 14 Nov 2014 13:08:35 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kx10so17530494pab.34 for ; Fri, 14 Nov 2014 05:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k91e6+X4iCJo8otmRKo8iS0pLtFK6YhROZ6Rlf3HI98=; b=nM0e38ZwQkwXNODNyGE6/RbEA0SilHtfzn4RDjwrm7T4Uqe2XWxDBynCucl/WBC29o J7LPVvHuTMl4cFdYy/ds4PFbUnl8DIjmGT/Xv2hyQaTb8XbYQdie0prnXEp05Al4JssP w8YBsptGtr10JQ0QnpJKi2/IcfAuU4JyqVHgjdsOSYChlwOOwSVfaIbb3bDjSPeN+Tjx B5LuHe3bnNW7Wnmmk9Jt6QD9EOxV/YP4ka0OpnRNaE0SLeiVmA3+E9OMxBXE5pQ3SHh1 pRKwNi4EzGZ/fcahqMjgxekyCmmlB5X+RCt2oiFkZ9Qq/DpMpP2I9Sl2XMo4QeWA/xpY SSHg== MIME-Version: 1.0 X-Received: by 10.70.131.199 with SMTP id oo7mr10079581pdb.138.1415970513950; Fri, 14 Nov 2014 05:08:33 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.73.2 with HTTP; Fri, 14 Nov 2014 05:08:33 -0800 (PST) In-Reply-To: References: <9734b7d34828a102d9a2f5061c11ae3d@mail.bakulin.de> Date: Fri, 14 Nov 2014 14:08:33 +0100 X-Google-Sender-Auth: vE7hR9KrsnB7cD3PU_p5tm3KvRU Message-ID: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Ilya Bakulin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Freebsd hackers list , freebsd-net , J David , owner-freebsd-net@freebsd.org, "freebsd-pf@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:08:35 -0000 Hello Ilya, just approval from some people. I will follow-up. On Fri, Nov 14, 2014 at 1:34 PM, Ilya Bakulin wrote: > Hi Ermal, > yes, this patch works for both #179392 and #172648. > > What do you need to merge this into -CURRENT and MFC to stable/9? > > > On 2014-11-14 12:57, Ermal Lu=C3=A7i wrote: > > Here is a direct patch. > > Give it a try. > > > > For the reply-to issues there is another patch complementary to this i > > will send. > > > > On Fri, Nov 14, 2014 at 11:34 AM, Ilya Bakulin > > wrote: > > > >> Hi all, > >> > >> actually with _my_ checksumming patch the rdr-to is broken > >> completely :-( > >> So I'm waiting for Ermal to send an updated version of his patch > >> that may really solve the problem! > >> > >> On 2014-11-14 09:17, Ermal Lu=C3=A7i wrote: > >> Yes confirmed it will solve that issue as well. > >> > >> On Thu, Nov 13, 2014 at 9:30 PM, J David > >> wrote: > >> > >> On Wed, Nov 5, 2014 at 9:28 AM, Ilya Bakulin > >> wrote: > >>> Of course it was interesting what does the upstream PF do (@ > >> OpenBSD). > >> Seems > >>> they have made the decision to > >>> leave the task of recalculating the checksums for outgoing > >> packets to > >>> ip[6]_output, because currently > >>> the code there overwrites the checksum anyway. > >>> This seems a correct way to me. pf should not longer do any > >> checksum > >> updates > >>> in inbound and outbound path. > >> > >> Is there any chance this change would help with bug 179392 as well? > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D179392 [1] > >> > >> Or is that a separate issue? > >> > >> Thanks! > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net [2] > >> To unsubscribe, send any mail to > >> "freebsd-net-unsubscribe@freebsd.org" > > > > -- > > > > Ermal > > > > Links: > > ------ > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D179392 > > [2] http://lists.freebsd.org/mailman/listinfo/freebsd-net > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. --=20 Ermal From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 12:47:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A00C5327; Fri, 14 Nov 2014 12:47:57 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5883912; Fri, 14 Nov 2014 12:47:56 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 1241C6A6004; Fri, 14 Nov 2014 13:47:55 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id sAEClseB010688; Fri, 14 Nov 2014 13:47:54 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id sAEClrAJ009989; Fri, 14 Nov 2014 13:47:53 +0100 (CET) (envelope-from lars) Date: Fri, 14 Nov 2014 13:47:53 +0100 From: Lars Engels To: Rui Paulo Subject: Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.) Message-ID: <20141114124753.GS34846@e-new.0x20.net> References: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MT9SxUWSsctiw0kG" Content-Disposition: inline In-Reply-To: <2FA736F4-8D06-4BBC-81DC-3E3A646BD391@me.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p16 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Fri, 14 Nov 2014 13:58:05 +0000 Cc: "Wojciech A. Koszek" , "freebsd-hackers@freebsd.org" , Luigi Rizzo , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 12:47:57 -0000 --MT9SxUWSsctiw0kG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: > On Nov 13, 2014, at 17:40, Luigi Rizzo wrote: > > But please nuke the current list -- it is completely inadequate > > for the code-in candidates and misleading for whoever wants to > > suggest new tasks. Again i am not saying that the projects > > suggested there are not important, just belong somewhere else > > e.g. gsoc. >=20 > I refrained from voicing my opinion while the call for help was going > on, but I completely agree that the target age of this Google > initiative is inadequate to FreeBSD. The target population is 13 > years to 17 years old and I cannot even imagine a 13 year old knowing > what FreeBSD is. >=20 > I'm not sure we should participate in Code In ever again and perhaps > we should focus our efforts on Summer of Code only. >=20 We could give them some simpler tasks like doing something on the wiki, cre= ate FreeBSD advocacy stuff or working on the website. --MT9SxUWSsctiw0kG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUZfn5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tK0YH/0jYccSSgrwOSabDMi+8NIqY g71W+x226w1G1jcVdHQ6bUEz7v+CLBpZ+c7H5XWc3OBVp8lDURyoQR+JdRR2thiR f1GK774HcJNES6NBM4KXVOpFbUSJyG2t5jHDPCXdXkWrFhelw5/HXhalJ/bn/ep5 qv8yA9/PVcaEnfupbSwljY7/p+ygRQ/nBBRzcM1JOSThLMvt23yQaXtBPP0aM9bk iEByT+MEeRD6W/kzmk1+pMitdwWed4EgJFi+FJY0Y916zRwQmRH+UBjiBTSabXII OTcfKaHCbcgFbtj10H3OTbJNlP6XnBcAKiB7t9B9DyaP9O/dKiRusUACuCKSwek= =ZW5A -----END PGP SIGNATURE----- --MT9SxUWSsctiw0kG-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 13:30:30 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88BCBE2E for ; Fri, 14 Nov 2014 13:30:30 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0063.outbound.protection.outlook.com [157.56.110.63]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2802F6C3 for ; Fri, 14 Nov 2014 13:30:29 +0000 (UTC) Received: from DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) by DM2PR04MB365.namprd04.prod.outlook.com (10.141.98.27) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 14 Nov 2014 09:54:24 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) by DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 14 Nov 2014 09:54:18 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.59]) by DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.59]) with mapi id 15.01.0016.006; Fri, 14 Nov 2014 09:54:18 +0000 From: Mike Gelfand To: Konstantin Belousov Subject: Re: [BUG] Getting path to program binary sometimes fails Thread-Topic: [BUG] Getting path to program binary sometimes fails Thread-Index: AQHP/y1OF6HbydE23kCBwyNP5wFRKZxeymWAgAEZIgA= Date: Fri, 14 Nov 2014 09:54:18 +0000 Message-ID: References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> In-Reply-To: <20141113170758.GY17068@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.140.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB477;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB477; x-forefront-prvs: 03950F25EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(189002)(71364002)(199003)(46102003)(77156002)(62966003)(66066001)(20776003)(95666004)(105586002)(64706001)(106116001)(106356001)(77096003)(21056001)(99286002)(99396003)(31966008)(107046002)(120916001)(110136001)(50986999)(76176999)(101416001)(54356999)(97736003)(33656002)(19580405001)(19580395003)(82746002)(2656002)(40100003)(92566001)(87936001)(92726001)(122556002)(86362001)(83716003)(36756003)(1411001)(4396001)(104396001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR04MB477; H:DM2PR04MB477.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <741FA9DE4BDB024B9C7030DCD2D981CF@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB365; X-OriginatorOrg: logicnow.com X-Mailman-Approved-At: Fri, 14 Nov 2014 13:58:23 +0000 Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:30:30 -0000 On Nov 13, 2014, at 8:07 PM, Konstantin Belousov wrot= e: > This is not a defect. The vnode->path translation uses namecache, which > could be purged at any time. The behaviour is typical for most unix > implementations. Linux and new Solaris have 'rigid' namecache, where > name entry lifetime is the same as the vnode lifetime it is attached to. > I am not aware of any useful consequences of such design, except > vn_fullpath() working more reliable, but at the cost of increased > memory usage. The man page for sysctl(3) states that =93Unless explicitly noted below, sy= sctl() returns a consistent snapshot of the data requested=94 (surely we do= n=92t expect half the path being returned; I=92m just trying to read thorou= ghly). Later on there are no special notes on {CTL_KERN, KERN_PROC, KERN_PR= OC_PATHNAME}; at least no notes on the unstable behavior being observed, an= d no funny details of internal implementation you describe. ERRORS section = only describes ENOENT condition as =93The name array specifies a value that= is unknown,=94 which certainly is not the case here. Since you=92re saying that current behavior is not a defect, maybe document= ation is wrong (incomplete, misleading) then? I will readily accept the =93= not a defect=94 explanation, but only if one wouldn=92t have to ask you eve= ry time this oddity is met. If this is the expected error condition, what s= hould I do to get the path reliably? Should I retry (and how many times)? Y= ou=92re saying cache is being purged; does it mean that when I ask for path= then cache is populated again? Does it guarantee then that I=92ll be able = to get the path on next call? Could you guarantee that I=92ll be able to ge= t the path at all if I fail two or more times? Should I rely on ENOENT spec= ifically when retrying? It would also be nice if you could tell whether anything had possibly chang= ed between 8 and 9 releases that could lead to this behavior. As I said bef= ore, same code works on FreeBSD 8 with no errors for more than two years. M= oreover, I didn=92t previously mention that but 8 and 9 systems which I=92m= currently testing on are installed on completely identical hardware. > Another possible reason for failed translation is the replacement of > the binary while it runs. There, rigid namecache does not help. Not the case here. Kind regards, Mike= From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 15 07:08:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 563A05DC for ; Sat, 15 Nov 2014 07:08:10 +0000 (UTC) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id D699B145 for ; Sat, 15 Nov 2014 07:08:09 +0000 (UTC) Received: from ppp118-210-137-175.lns20.adl6.internode.on.net (HELO midget.dons.net.au) ([118.210.137.175]) by ipmail05.adl6.internode.on.net with ESMTP; 15 Nov 2014 17:32:59 +1030 Received: from [10.0.2.95] ([10.0.2.95]) (authenticated bits=0) by midget.dons.net.au (8.14.6/8.14.4) with ESMTP id sAF72eNb097129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Nov 2014 17:32:47 +1030 (CST) (envelope-from darius@dons.net.au) From: "O'Connor, Daniel" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Nov 2014 17:32:39 +1030 Subject: Newbus question To: FreeBSD Hackers Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Spam-Score: -1.105 () BAYES_00,HELO_MISC_IP,RDNS_NONE,URIBL_BLOCKED X-Scanned-By: MIMEDefang 2.73 on 10.0.2.1 X-Mailman-Approved-At: Sat, 15 Nov 2014 12:28:09 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 07:08:10 -0000 Hi, I am trying to write a driver for the EHCI debug port [1]. I found some = userland code which I got working (written by the person who did the = Linux version) and now I am trying to get it running in the kernel. One = problem I have is that it needs to run in parallel with the normal EHCI = controller. It uses the same BAR as the EHCI controller but offset (the = offset is found in a PCI capability). I think I can bus_alloc_resource() = if I change EHCI to allocate with RF_SHAREABLE but my first problem is = to add another device so my driver doesn=92t contest with the EHCI = driver. Currently I have a module which loops over bus/slot/func using find_bsf = (is there a way to enumerate all connected PCI devices?) and then check = each for the debug capability (I plan on being a bit pickier later but = it works so far) then creating a child device. The problem is that the = probe routine=20 The code I have so far is at = https://gist.github.com/DanielO/f0f6643de567981a9a10 and the output I = get is.. Driver is dbgp Probed Driver is dbgp Probed Driver is dbgp Probed Driver is dbgp Probed Driver is dbgp Probed Driver is dbgp Probed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MOD_LOAD =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Found debug capability on 0.26.0 at 0xa0 map 0x14 start 0xf7f18000 length 1024 Child already present Found debug capability on 0.29.0 at 0xa0 map 0x14 start 0xf7f17000 length 1024 Child already present This is after a fresh reboot so I am a little perplexed.. 1 - Appendix C of = http://www.intel.com.au/content/dam/www/public/us/en/documents/technical-s= pecifications/ehci-specification-for-usb.pdf - http://komposter.com.ua/documents/USB-2.0-Debug-Port(John-Keys).pdf = has a nice overview -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 15 17:17:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67F16387 for ; Sat, 15 Nov 2014 17:17:38 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21121EE0 for ; Sat, 15 Nov 2014 17:17:38 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id c9so3640124qcz.19 for ; Sat, 15 Nov 2014 09:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=MuxI9TUPDkl9wPCjZJ9GcVh/K4ZE7VCwb3YUQ9XcIXg=; b=ld7G2QbtqT+Y4xUcFYKgR5Y6pzKVsROuchMWSTSCcb/S9PktQeUR300GANUGpzArvm obHINeVKlH7ys0+7DWL8XMF1OfTkdqMo3DnV7SQniQGDr3exfGRLI6UPWFbt5qu1quwF eE9s6wlx1RMeBKW3mjZ3r4mqG/adMNxEvbJHtc7CqT1SQ6f7RWygNs3DM3rHnXbCx3O1 68Kj3/BmJbwci+XI+1OJnF+jiJREnnj9QazXS8C53J9dVTQplYkxIP7lA13oTn5dpsXe oGLu+WF5IUnRP3lZixz/ihaMFsVm8OT3tL2p0aAFF3UNLRv+xhVG1G8V40GWbKoXzYm1 6IGA== X-Received: by 10.224.10.195 with SMTP id q3mr21080964qaq.8.1416071856406; Sat, 15 Nov 2014 09:17:36 -0800 (PST) Received: from kan ([2601:6:6780:7e0:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id m8sm30083544qag.25.2014.11.15.09.17.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Nov 2014 09:17:35 -0800 (PST) Date: Sat, 15 Nov 2014 12:17:30 -0500 From: Alexander Kabaev To: "O'Connor, Daniel" Subject: Re: Newbus question Message-ID: <20141115121730.3a5bac94@kan> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/oyipExaqpN.rvU7xy3OZF8P"; protocol="application/pgp-signature" Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 17:17:38 -0000 --Sig_/oyipExaqpN.rvU7xy3OZF8P Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Sat, 15 Nov 2014 17:32:39 +1030 "O'Connor, Daniel" wrote: > Hi, > I am trying to write a driver for the EHCI debug port [1]. I found > some userland code which I got working (written by the person who did > the Linux version) and now I am trying to get it running in the > kernel. One problem I have is that it needs to run in parallel with > the normal EHCI controller. It uses the same BAR as the EHCI > controller but offset (the offset is found in a PCI capability). I > think I can bus_alloc_resource() if I change EHCI to allocate with > RF_SHAREABLE but my first problem is to add another device so my > driver doesn't contest with the EHCI driver. >=20 > Currently I have a module which loops over bus/slot/func using > find_bsf (is there a way to enumerate all connected PCI devices?) and > then check each for the debug capability (I plan on being a bit > pickier later but it works so far) then creating a child device. The > problem is that the probe routine >=20 Hi, I do not think this can be done without cooperation of the ECHI device. You'd have to go the way of the full parent/child relationship between ehci parent and debug port child devices. Fortunately, this is not that hard to do and you can even define your own devmethod interfaces to make communication between debug port decoupled, so that debug port can be loaded and unloaded independently. The echi device already manages one child usbus device, adding another should not be too hard. --=20 Alexander Kabaev --Sig_/oyipExaqpN.rvU7xy3OZF8P Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iD8DBQFUZ4quQ6z1jMm+XZYRAmnGAKCW1kPEjSclBHUkYWUZjvL2nydMIwCfZ+4n 4JJgm/FglzZfIu3lr973uk8= =tGtX -----END PGP SIGNATURE----- --Sig_/oyipExaqpN.rvU7xy3OZF8P-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 15 18:03:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C20CFB5 for ; Sat, 15 Nov 2014 18:03:56 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3DBF364 for ; Sat, 15 Nov 2014 18:03:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAFI33sv045970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 20:03:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAFI33sv045970 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAFI32FW045969; Sat, 15 Nov 2014 20:03:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 15 Nov 2014 20:03:02 +0200 From: Konstantin Belousov To: Alexander Kabaev Subject: Re: Newbus question Message-ID: <20141115180302.GL17068@kib.kiev.ua> References: <20141115121730.3a5bac94@kan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141115121730.3a5bac94@kan> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Hackers , "O'Connor, Daniel" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 18:03:56 -0000 On Sat, Nov 15, 2014 at 12:17:30PM -0500, Alexander Kabaev wrote: > On Sat, 15 Nov 2014 17:32:39 +1030 > "O'Connor, Daniel" wrote: > > > Hi, > > I am trying to write a driver for the EHCI debug port [1]. I found > > some userland code which I got working (written by the person who did > > the Linux version) and now I am trying to get it running in the > > kernel. One problem I have is that it needs to run in parallel with > > the normal EHCI controller. It uses the same BAR as the EHCI > > controller but offset (the offset is found in a PCI capability). I > > think I can bus_alloc_resource() if I change EHCI to allocate with > > RF_SHAREABLE but my first problem is to add another device so my > > driver doesn't contest with the EHCI driver. > > > > Currently I have a module which loops over bus/slot/func using > > find_bsf (is there a way to enumerate all connected PCI devices?) and > > then check each for the debug capability (I plan on being a bit > > pickier later but it works so far) then creating a child device. The > > problem is that the probe routine > > > > Hi, > > I do not think this can be done without cooperation of the ECHI device. > You'd have to go the way of the full parent/child relationship between > ehci parent and debug port child devices. Fortunately, this is not that > hard to do and you can even define your own devmethod interfaces to make > communication between debug port decoupled, so that debug port can be > loaded and unloaded independently. The echi device already manages one > child usbus device, adding another should not be too hard. I think that debugging should be available much earlier than the device tree is explored and devices are attached. It probably makes sense to operate the debugging port outside the newbus at all, in particular, before the pci and acpi machinery is initialized. You might want a callback from ehci driver when it appropriated the resources, to handle the case of bar realocation. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 15 18:35:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5608AA52 for ; Sat, 15 Nov 2014 18:35:33 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0904B873 for ; Sat, 15 Nov 2014 18:35:33 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id i17so412711qcy.4 for ; Sat, 15 Nov 2014 10:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=tLxVnntU5kKPoNRp8hf0UTPPi8SKvibGzPawK8cmSOY=; b=h/2lfnLBc5yry8ADKPM499cSVPOD1kipPAtmZ5fwHbfsU1CTMuemd8vtna5Hl20QSb HrqeCA0ZmIuOkVbjqfLbCts1SCE6BRP8DSBYXFAS5eTqlGktAjs7DkNDHENvsbYezsqi 1ekD0P+L1vOid9hlA3zUHvSz4TiMVOvIkR7oUZ+nZH0kXSLuSE+3t2KZCcRdR9C8Z77E vFUZkfziVFWGqZ5jA2WMd/9Dj7x2FLI29zCFxB4zZdfGvdZ7Ukup9pgIgyCDXo3k26f1 2Va18oZtZrv0hcYKLMs5f1gxnLo3mY+WenrPXzjySsar7CCSN9CMYk62frKgzCYe0PKW PQow== X-Received: by 10.140.109.102 with SMTP id k93mr20717480qgf.83.1416076532187; Sat, 15 Nov 2014 10:35:32 -0800 (PST) Received: from kan ([2601:6:6780:7e0:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id e2sm26577728qaw.10.2014.11.15.10.35.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Nov 2014 10:35:31 -0800 (PST) Date: Sat, 15 Nov 2014 13:35:25 -0500 From: Alexander Kabaev To: Konstantin Belousov Subject: Re: Newbus question Message-ID: <20141115133525.51a25bfa@kan> In-Reply-To: <20141115180302.GL17068@kib.kiev.ua> References: <20141115121730.3a5bac94@kan> <20141115180302.GL17068@kib.kiev.ua> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/zdH5dEGZSdVN.dvL+KgPvlK"; protocol="application/pgp-signature" Cc: FreeBSD Hackers , "O'Connor, Daniel" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 18:35:33 -0000 --Sig_/zdH5dEGZSdVN.dvL+KgPvlK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 15 Nov 2014 20:03:02 +0200 Konstantin Belousov wrote: > On Sat, Nov 15, 2014 at 12:17:30PM -0500, Alexander Kabaev wrote: > > On Sat, 15 Nov 2014 17:32:39 +1030 > > "O'Connor, Daniel" wrote: > >=20 > > > Hi, > > > I am trying to write a driver for the EHCI debug port [1]. I found > > > some userland code which I got working (written by the person who > > > did the Linux version) and now I am trying to get it running in > > > the kernel. One problem I have is that it needs to run in > > > parallel with the normal EHCI controller. It uses the same BAR as > > > the EHCI controller but offset (the offset is found in a PCI > > > capability). I think I can bus_alloc_resource() if I change EHCI > > > to allocate with RF_SHAREABLE but my first problem is to add > > > another device so my driver doesn't contest with the EHCI driver. > > >=20 > > > Currently I have a module which loops over bus/slot/func using > > > find_bsf (is there a way to enumerate all connected PCI devices?) > > > and then check each for the debug capability (I plan on being a > > > bit pickier later but it works so far) then creating a child > > > device. The problem is that the probe routine > > >=20 > >=20 > > Hi, > >=20 > > I do not think this can be done without cooperation of the ECHI > > device. You'd have to go the way of the full parent/child > > relationship between ehci parent and debug port child devices. > > Fortunately, this is not that hard to do and you can even define > > your own devmethod interfaces to make communication between debug > > port decoupled, so that debug port can be loaded and unloaded > > independently. The echi device already manages one child usbus > > device, adding another should not be too hard. >=20 > I think that debugging should be available much earlier than the > device tree is explored and devices are attached. It probably makes > sense to operate the debugging port outside the newbus at all, in > particular, before the pci and acpi machinery is initialized. >=20 > You might want a callback from ehci driver when it appropriated the > resources, to handle the case of bar realocation. If one wants early debugger, then whole thing will need to be split into pre-newbus and after-newbus part, similar to dcons. --=20 Alexander Kabaev --Sig_/zdH5dEGZSdVN.dvL+KgPvlK Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iD8DBQFUZ5zyQ6z1jMm+XZYRArBYAKCPkMvxTCPipwB+JrmkIWXJtqhmgwCeJBiY fN2PO89HbxB7Pha4Ex9QJSU= =zG0Q -----END PGP SIGNATURE----- --Sig_/zdH5dEGZSdVN.dvL+KgPvlK-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 15 22:42:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3E159CE for ; Sat, 15 Nov 2014 22:42:01 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 654A3DF for ; Sat, 15 Nov 2014 22:42:01 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id ij19so4745510vcb.36 for ; Sat, 15 Nov 2014 14:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zmZHK5ibqvhGYTMtroCnR+hgJbAzAFG9k1g48F1m4ws=; b=aTP5L/UG1vVb5IYKyhFeOTNbXfXuT+MPDwpX1078ZR6qQoClqim2bU9ONBAD/5Dkeg Jz5Wk/ZDSDpwKr8QWbL3LqwCA/GdL63AZTXuM8Ej5pRBykxj8GVpe+tUs1VKBSryN4T+ uqFR+Stn/rRDHQKlnrDbbqJtP7ypFzPkghi5ujrMiYuF6e4vS8tD5Ojdjoc9t56U+D6B q3mqsg5kUZfQk+X2+NL99asrknYDEgnKX7umwGLDcMW2/iZzwChtHzM0LkoocWYwkjhA hLK6hFXDfF51oeNmWCVSrK+B3FkGOW86zJQ8ZBbY7AEMLSEQpwA74+K0sy3Zt3MB36PH 3Mug== MIME-Version: 1.0 X-Received: by 10.52.12.198 with SMTP id a6mr12833915vdc.4.1416091320440; Sat, 15 Nov 2014 14:42:00 -0800 (PST) Received: by 10.220.118.19 with HTTP; Sat, 15 Nov 2014 14:42:00 -0800 (PST) Date: Sat, 15 Nov 2014 17:42:00 -0500 Message-ID: Subject: OT-ish SATA port replicators vs. SAS "expanders" From: Zaphod Beeblebrox To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 22:42:01 -0000 First... seriously... whoever was working on this naming convention thought "expanders" was a good name? Anyways... I don't talk about big piles of disk in any other forum, so I'm asking here. The very first different between SATA port replicators and SAS expanders is that I can find many working examples of the former, while the latter are very scarce. The latter also seem to be expensive, as is anything else labelled with SAS. I have, for some time, been running a ZFS array that makes uses of SATA port replicators. Because I had some CRC errors, someone suggested I look at other SATA ports, and I settled on the Supermicro clone of the LSI 2008. The problem with the LSI 2008 is that it doesn't support SATA port replicators (while it does support SAS expanders). What is the real difference? Is it possible to hack the driver to support (obviously not booting from) SATA port replicators on the LSI?