From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 15:04:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AEE51065676 for ; Mon, 13 Feb 2012 15:04:31 +0000 (UTC) (envelope-from ssanders@softhammer.net) Received: from smtp-hq2.opnet.com (smtp-hq2.opnet.com [192.104.65.247]) by mx1.freebsd.org (Postfix) with ESMTP id 198568FC0C for ; Mon, 13 Feb 2012 15:04:31 +0000 (UTC) Received: from [172.16.9.10] (wtn09010.opnet.com [172.16.9.10]) by smtp.opnet.com (Postfix) with ESMTPSA id CBFCD211023A for ; Mon, 13 Feb 2012 09:48:09 -0500 (EST) Message-ID: <4F3922A8.2090808@softhammer.net> Date: Mon, 13 Feb 2012 09:48:08 -0500 From: Stephen Sanders User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Odd RAID Performance Issue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:04:31 -0000 We've an application that logs data on one very large raid6 array and updates/accesses a database on another smaller raid5 array. Both arrays are connected to the same PCIe 3ware RAID controller. The system has 2 six core 3Ghz processors and 24 GB of RAM. The system is running FreeBSD 8.1. The averaged read/write rate to the database is 2MB/s while the averaged write raid to the data logging array is 300MB/s. Writes to the logging array are somewhat bursty. The problem we're encountering is that the disk subsystem appears to 'pause' periodically. It looks as if this is a result of disk read/write operations from the database array taking a very long time to complete (up to 8 sec). When the disk read operation takes such a long time, it appears that the system starts to run out of memory due to bio block buffering. Most processes end up in either getblk() or waithighrunning(). We've instrumented g_vfs_strategie() and bufdone_finish() using dtrace. The indication from this effort is that a number of reads and writes are taking 4-8 seconds. So far, it looks as if the disk driver and hardware are OK as read/write operations appear to be in the milli-second region. We believe that our instrumentation is pointing to something between the VFS layer and the CAM as the culprit. We've gotten the same result from FreeBSD 8.2 but have not tried FreeBSD 9 as yet. This scenario is not limited to a single system and is occurring on a couple of systems. Does this sound familiar to anyone out there? Thanks From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 15:46:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C32DA1065672 for ; Mon, 13 Feb 2012 15:46:08 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8191B8FC17 for ; Mon, 13 Feb 2012 15:46:08 +0000 (UTC) Received: by vcmm1 with SMTP id m1so4681489vcm.13 for ; Mon, 13 Feb 2012 07:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/nuL/wI9Ei6Qp1HShRZstzAWahDp0X+gM9sA40yLfoU=; b=aetPujmEJ6NTl6LprGq221gnvTCByziDTBcZ/l+Yd/2Co+UcZgVhbKZH5X0khVTRN/ zXK+W6OcZeuX+tb7329/0sBRAZ5xXHuHM6frmtEY+r6zqyyCFUZC87Fu6t4HhNbMV8tY sp/Kr2P6eJ0IoxQR/rytJiOSMjsRY8O2QuhYM= MIME-Version: 1.0 Received: by 10.220.151.67 with SMTP id b3mr8431813vcw.51.1329147967854; Mon, 13 Feb 2012 07:46:07 -0800 (PST) Received: by 10.52.91.210 with HTTP; Mon, 13 Feb 2012 07:46:07 -0800 (PST) In-Reply-To: <4F3922A8.2090808@softhammer.net> References: <4F3922A8.2090808@softhammer.net> Date: Mon, 13 Feb 2012 15:46:07 +0000 Message-ID: From: Tom Evans To: Stephen Sanders Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Odd RAID Performance Issue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:46:08 -0000 On Mon, Feb 13, 2012 at 2:48 PM, Stephen Sanders wrote: > We've an application that logs data on one very large raid6 array > and updates/accesses a database on another smaller raid5 array. > > Both arrays are connected to the same PCIe 3ware RAID controller. =C2=A0 = The > system has 2 six core 3Ghz processors and 24 GB of RAM. =C2=A0The system = is > running FreeBSD 8.1. > > The averaged read/write rate to the database is 2MB/s while the averaged > write raid to the data =C2=A0logging array is 300MB/s. =C2=A0Writes to th= e logging > array are somewhat bursty. > > The problem we're encountering is that the disk subsystem appears to > 'pause' periodically. =C2=A0 It looks as if this is a result of disk read= /write > operations from the database array taking a very long time to complete > (up to 8 sec). > > When the disk read operation takes such a long time, it appears that the > system starts to run out of memory due to bio block buffering. =C2=A0Most > processes end up in either getblk() or waithighrunning(). > > We've instrumented g_vfs_strategie() and bufdone_finish() using dtrace. > The indication from this effort is that a number of reads and writes are > taking 4-8 seconds. > > So far, it looks as if the disk driver and hardware are OK as read/write > operations appear to be in the milli-second region. =C2=A0We believe that= our > instrumentation is pointing to something between the VFS layer and the > CAM as the culprit. > > We've gotten the same result from FreeBSD 8.2 but have not tried FreeBSD > 9 as yet. > > This scenario is not limited to a single system and is occurring on a > couple of systems. > > Does this sound familiar to anyone out there? > > Thanks Do you have a BBU on the 3ware device? It sounds very similar to effects we used to suffer when we used servers with twa without a BBU. Our newer servers use LSI/Dell PERC (with BBUs!), and don't have this sort of issue anymore. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 16:51:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7252106564A for ; Mon, 13 Feb 2012 16:51:46 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7923A8FC1C for ; Mon, 13 Feb 2012 16:51:46 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Rwz7x-0001hj-BX for freebsd-hackers@freebsd.org; Mon, 13 Feb 2012 17:51:45 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Feb 2012 17:51:45 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Feb 2012 17:51:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 13 Feb 2012 17:51:35 +0100 Lines: 49 Message-ID: References: <4F3922A8.2090808@softhammer.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30C27DE334A3890B8C08E44E" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <4F3922A8.2090808@softhammer.net> X-Enigmail-Version: 1.3.5 Subject: Re: Odd RAID Performance Issue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:51:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30C27DE334A3890B8C08E44E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13/02/2012 15:48, Stephen Sanders wrote: > We've an application that logs data on one very large raid6 array > and updates/accesses a database on another smaller raid5 array. You would be better off with RAID10 for a database (or anything which does random IO). > Both arrays are connected to the same PCIe 3ware RAID controller. The= > system has 2 six core 3Ghz processors and 24 GB of RAM. The system is > running FreeBSD 8.1. Did you do any additional OS tuning? Do you use UFS or ZFS? > The problem we're encountering is that the disk subsystem appears to > 'pause' periodically. It looks as if this is a result of disk read/wr= ite > operations from the database array taking a very long time to complete > (up to 8 sec). You should be able to monitor this with "iostat -x 1" (or whatever number of seconds instead of "1") - the last three columns should tell you if the device(s) are extraordinarily busy, and the r/s and w/s columns should tell you what the real IOPS rate is. You should probably post a sample output from this command when the problem appears. --------------enig30C27DE334A3890B8C08E44E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85P5cACgkQldnAQVacBcjySgCfSpFYYZBfvTXUmAaC3ONDpAmO aVcAn3cTAUGdYVRiFIOm8l6lFSvU6eQ2 =xvj2 -----END PGP SIGNATURE----- --------------enig30C27DE334A3890B8C08E44E-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 19:57:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D007106566C; Mon, 13 Feb 2012 19:57:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 96C3E8FC13; Mon, 13 Feb 2012 19:57:28 +0000 (UTC) Received: by eekb47 with SMTP id b47so2243341eek.13 for ; Mon, 13 Feb 2012 11:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=a1qqtJUMOr8gjjShKuVthnvAOVm9NBbDYiHottTMAWY=; b=p1YM3bGKWS2Bn2Gch8P5/Mun8D4xxtH3V/nmI4/4yNN5gUSVpUBszh0x6Bjwzi0qY8 gc67wW8h/P/MjbNZ28u6wxLNl/1mgQIHMsup09Bzd+2vFOqKC6w7yEZqSRRxNiJ0DaDH Qpy3zbQnXqAefeFpNdWncteKKBCY5UlSXRPcw= Received: by 10.14.95.129 with SMTP id p1mr5908439eef.10.1329163047480; Mon, 13 Feb 2012 11:57:27 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n52sm4957768eea.5.2012.02.13.11.57.25 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 11:57:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4F396B24.5090602@FreeBSD.org> Date: Mon, 13 Feb 2012 21:57:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Andriy Gapon References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> In-Reply-To: <4F367965.6000602@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:57:29 -0000 On 02/11/12 16:21, Alexander Motin wrote: > I've heavily rewritten the patch already. So at least some of the ideas > are already addressed. :) At this moment I am mostly satisfied with > results and after final tests today I'll probably publish new version. It took more time, but finally I think I've put pieces together: http://people.freebsd.org/~mav/sched.htt23.patch The patch is more complicated then previous one both logically and computationally, but with growing CPU power and complexity I think we can possibly spend some more time deciding how to spend time. :) Patch formalizes several ideas of the previous code about how to select CPU for running a thread and adds some new. It's main idea is that I've moved from comparing raw integer queue lengths to higher-resolution flexible values. That additional 8-bit precision allows same time take into account many factors affecting performance. Beside just choosing best from equally-loaded CPUs, with new code it may even happen that because of SMT, cache affinity, etc, CPU with more threads on it's queue will be reported as less loaded and opposite. New code takes into account such factors: - SMT sharing penalty. - Cache sharing penalty. - Cache affinity (with separate coefficients for last-level and other level caches) to the: - other running threads of it's process, - previous CPU where it was running, - current CPU (usually where it was called from). All of these factors are configurable via sysctls, but I think reasonable defaults should fit most. Also, comparing to previous patch, I've resurrected optimized shortcut in CPU selection for the case of SMT. Comparing to original code having problems with this, I've added check for other logical cores load that should make it safe and still very fast when there are less running threads then physical cores. I've tested in on Core i7 and Atom systems, but more interesting would be to test it on multi-socket system with properly detected topology to check benefits from affinity. At this moment the main issue I see is that this patch affects only time when thread is starting. If thread runs continuously, it will stay where it was, even if due to situation change that is not very effective (causes SMT sharing, etc). I haven't looked much on periodic load balancer yet, but probably it could also be somehow improved. What is your opinion, is it too over-engineered, or it is the right way to go? -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 20:47:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08F4E106566C; Mon, 13 Feb 2012 20:47:29 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id AD5888FC0A; Mon, 13 Feb 2012 20:47:28 +0000 (UTC) Received: by iaeo4 with SMTP id o4so5924184iae.13 for ; Mon, 13 Feb 2012 12:47:28 -0800 (PST) Received: by 10.42.148.197 with SMTP id s5mr24153663icv.45.1329164563257; Mon, 13 Feb 2012 12:22:43 -0800 (PST) Received: from [72.253.42.56] ([72.253.42.56]) by mx.google.com with ESMTPS id wn7sm15544246igc.0.2012.02.13.12.22.40 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 12:22:41 -0800 (PST) Date: Mon, 13 Feb 2012 10:23:36 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alexander Motin In-Reply-To: <4F396B24.5090602@FreeBSD.org> Message-ID: References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQnzahpLMcaV9KuOSHtnnvjREZ3TDUQmOTGln2MnFGZOIYQbMg+hbwtFl2beC/IU5DNMh1Zn X-Mailman-Approved-At: Mon, 13 Feb 2012 20:49:42 +0000 Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:47:29 -0000 On Mon, 13 Feb 2012, Alexander Motin wrote: > On 02/11/12 16:21, Alexander Motin wrote: >> I've heavily rewritten the patch already. So at least some of the ideas >> are already addressed. :) At this moment I am mostly satisfied with >> results and after final tests today I'll probably publish new version. > > It took more time, but finally I think I've put pieces together: > http://people.freebsd.org/~mav/sched.htt23.patch I need some time to read and digest this. However, at first glance, a global pickcpu lock will not be acceptable. Better to make a rarely imperfect decision than too often cause contention. > > The patch is more complicated then previous one both logically and > computationally, but with growing CPU power and complexity I think we can > possibly spend some more time deciding how to spend time. :) > It is probably worth more cycles but we need to evaluate this much more complex algorithm carefully to make sure that each of these new features provides an advantage. > Patch formalizes several ideas of the previous code about how to select CPU > for running a thread and adds some new. It's main idea is that I've moved > from comparing raw integer queue lengths to higher-resolution flexible > values. That additional 8-bit precision allows same time take into account > many factors affecting performance. Beside just choosing best from > equally-loaded CPUs, with new code it may even happen that because of SMT, > cache affinity, etc, CPU with more threads on it's queue will be reported as > less loaded and opposite. > > New code takes into account such factors: > - SMT sharing penalty. > - Cache sharing penalty. > - Cache affinity (with separate coefficients for last-level and other level > caches) to the: We already used separate affinity values for different cache levels. Keep in mind that if something else has run on a core the cache affinity is lost in very short order. Trying too hard to preserve it beyond a few ms never seems to pan out. > - other running threads of it's process, This is not really a great indicator of whether things should be scheduled together or not. What workload are you targeting here? > - previous CPU where it was running, > - current CPU (usually where it was called from). These two were also already used. Additionally: + * Hide part of the current thread + * load, hoping it or the scheduled + * one complete soon. + * XXX: We need more stats for this. I had something like this before. Unfortunately interactive tasks are allowed fairly aggressive bursts of cpu to account for things like xorg and web browsers. Also, I tried this for ithreads but they can be very expensive in some workloads so other cpus will idle as you try to schedule behind an ithread. > All of these factors are configurable via sysctls, but I think reasonable > defaults should fit most. > > Also, comparing to previous patch, I've resurrected optimized shortcut in CPU > selection for the case of SMT. Comparing to original code having problems > with this, I've added check for other logical cores load that should make it > safe and still very fast when there are less running threads then physical > cores. > > I've tested in on Core i7 and Atom systems, but more interesting would be to > test it on multi-socket system with properly detected topology to check > benefits from affinity. > > At this moment the main issue I see is that this patch affects only time when > thread is starting. If thread runs continuously, it will stay where it was, > even if due to situation change that is not very effective (causes SMT > sharing, etc). I haven't looked much on periodic load balancer yet, but > probably it could also be somehow improved. > > What is your opinion, is it too over-engineered, or it is the right way to > go? I think it's a little too much change all at once. I also believe that the changes that try very hard to preserve affinity likely help a much smaller number of cases than they hurt. I would prefer you do one piece at a time and validate each step. There are a lot of good ideas in here but good ideas don't always turn into results. Thanks, Jeff > > -- > Alexander Motin > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 20:55:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6DD2106564A; Mon, 13 Feb 2012 20:55:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 015F38FC0A; Mon, 13 Feb 2012 20:55:28 +0000 (UTC) Received: by eaan10 with SMTP id n10so2177390eaa.13 for ; Mon, 13 Feb 2012 12:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=w1Zy35I7j203IHbjrTWNdFp/FPxhDSfiS3aXYI/60pA=; b=oXB45uWwjr11zFuxamUuvzrUMuC83g7uu6IUqRqgeTiP6YGk6Mhsn7TEry94GahKQU EIZksVIssUaravKiXr9fCXeP8vCE3JBn6RuoKwcHon3xIhGQkPWSLxpgAlGV+IwVkEJR p23NY3zteJIuVZo5LEZ4vJGixaJP7zUlWuEPU= Received: by 10.213.13.206 with SMTP id d14mr3072107eba.4.1329166527801; Mon, 13 Feb 2012 12:55:27 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id o49sm64929699eei.0.2012.02.13.12.55.25 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 12:55:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3978BC.6090608@FreeBSD.org> Date: Mon, 13 Feb 2012 22:55:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:55:29 -0000 On 02/13/12 22:23, Jeff Roberson wrote: > On Mon, 13 Feb 2012, Alexander Motin wrote: > >> On 02/11/12 16:21, Alexander Motin wrote: >>> I've heavily rewritten the patch already. So at least some of the ideas >>> are already addressed. :) At this moment I am mostly satisfied with >>> results and after final tests today I'll probably publish new version. >> >> It took more time, but finally I think I've put pieces together: >> http://people.freebsd.org/~mav/sched.htt23.patch > > I need some time to read and digest this. However, at first glance, a > global pickcpu lock will not be acceptable. Better to make a rarely > imperfect decision than too often cause contention. On my tests it was opposite. Imperfect decisions under 60K MySQL requests per second on 8 cores quite often caused two threads to be pushed to one CPU or to one physical core, causing up to 5-10% performance penalties. I've tried both with and without lock and at least on 8-core machine difference was significant to add this. I understand that this is not good, but I have no machine with hundred of CPUs to tell how will it work there. For really big systems it could be partitioned somehow, but that will also increase load imbalance. >> The patch is more complicated then previous one both logically and >> computationally, but with growing CPU power and complexity I think we >> can possibly spend some more time deciding how to spend time. :) > > It is probably worth more cycles but we need to evaluate this much more > complex algorithm carefully to make sure that each of these new features > provides an advantage. Problem is that doing half of things may not give full picture. How to do affinity trying to save some percents, while SMT effect is times higher? Same time too many unknown variables in applications behavior can easily make all of this pointless. >> Patch formalizes several ideas of the previous code about how to >> select CPU for running a thread and adds some new. It's main idea is >> that I've moved from comparing raw integer queue lengths to >> higher-resolution flexible values. That additional 8-bit precision >> allows same time take into account many factors affecting performance. >> Beside just choosing best from equally-loaded CPUs, with new code it >> may even happen that because of SMT, cache affinity, etc, CPU with >> more threads on it's queue will be reported as less loaded and opposite. >> >> New code takes into account such factors: >> - SMT sharing penalty. >> - Cache sharing penalty. >> - Cache affinity (with separate coefficients for last-level and other >> level caches) to the: > > We already used separate affinity values for different cache levels. > Keep in mind that if something else has run on a core the cache affinity > is lost in very short order. Trying too hard to preserve it beyond a few > ms never seems to pan out. Previously it was only about timeout, that was IMHO pointless, as it is impossible to predict when cache will be purged. It could be done in microsecond or second later, depending on application behavior. >> - other running threads of it's process, > > This is not really a great indicator of whether things should be > scheduled together or not. What workload are you targeting here? When several threads accessing/modifying same shared memory. Like MySQL server threads. I've noticed that on Atom CPU wit no L3 it is cheaper to move two threads to one physical core to share the cache then handle coherency over the memory bus. >> - previous CPU where it was running, >> - current CPU (usually where it was called from). > > These two were also already used. Additionally: > > + * Hide part of the current thread > + * load, hoping it or the scheduled > + * one complete soon. > + * XXX: We need more stats for this. > > I had something like this before. Unfortunately interactive tasks are > allowed fairly aggressive bursts of cpu to account for things like xorg > and web browsers. Also, I tried this for ithreads but they can be very > expensive in some workloads so other cpus will idle as you try to > schedule behind an ithread. As I have noted, this need more precise statistics about thread behavior. Present sampled statistics is almost useless there. Existing code always prefers to run thread on current CPU if there is no other CPU with no load. That logic works very good when 8 MySQL threads and 8 clients working on 8 CPUs, but a bit not so good in other situations. >> All of these factors are configurable via sysctls, but I think >> reasonable defaults should fit most. >> >> Also, comparing to previous patch, I've resurrected optimized shortcut >> in CPU selection for the case of SMT. Comparing to original code >> having problems with this, I've added check for other logical cores >> load that should make it safe and still very fast when there are less >> running threads then physical cores. >> >> I've tested in on Core i7 and Atom systems, but more interesting would >> be to test it on multi-socket system with properly detected topology >> to check benefits from affinity. >> >> At this moment the main issue I see is that this patch affects only >> time when thread is starting. If thread runs continuously, it will >> stay where it was, even if due to situation change that is not very >> effective (causes SMT sharing, etc). I haven't looked much on periodic >> load balancer yet, but probably it could also be somehow improved. >> >> What is your opinion, is it too over-engineered, or it is the right >> way to go? > > I think it's a little too much change all at once. I also believe that > the changes that try very hard to preserve affinity likely help a much > smaller number of cases than they hurt. I would prefer you do one piece > at a time and validate each step. There are a lot of good ideas in here > but good ideas don't always turn into results. When each of these small steps can change everything and they are related, number of combinations to test grows rapidly. I am not going to commit this tomorrow. It is more like concept, that needs testing and evaluation. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 21:13:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D72AA1065670 for ; Mon, 13 Feb 2012 21:13:52 +0000 (UTC) (envelope-from Aaron.Caza@ca.weatherford.com) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7FBAD8FC1A for ; Mon, 13 Feb 2012 21:13:52 +0000 (UTC) Received: from mail55-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Feb 2012 20:58:47 +0000 Received: from mail55-tx2 (localhost [127.0.0.1]) by mail55-tx2-R.bigfish.com (Postfix) with ESMTP id B84F22C0257 for ; Mon, 13 Feb 2012 20:58:46 +0000 (UTC) X-SpamScore: -8 X-BigFish: PS-8(zzc85fhfb6I55dRzz1202hzzz2fh2a8h668h839h8e2h8e3hbe9k) X-Forefront-Antispam-Report: CIP:70.37.183.126; KIP:(null); UIP:(null); IPV:NLI; H:owa.weatherford.com; RD:none; EFVD:NLI Received-SPF: pass (mail55-tx2: domain of ca.weatherford.com designates 70.37.183.126 as permitted sender) client-ip=70.37.183.126; envelope-from=Aaron.Caza@ca.weatherford.com; helo=owa.weatherford.com ; therford.com ; Received: from mail55-tx2 (localhost.localdomain [127.0.0.1]) by mail55-tx2 (MessageSwitch) id 1329166721726184_9808; Mon, 13 Feb 2012 20:58:41 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.248]) by mail55-tx2.bigfish.com (Postfix) with ESMTP id 8F309300055 for ; Mon, 13 Feb 2012 20:58:41 +0000 (UTC) Received: from owa.weatherford.com (70.37.183.126) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Feb 2012 20:58:38 +0000 Received: from 032-SN1MPN1-005.032d.mgd.msft.net ([169.254.5.114]) by 032-SN1MMR1-002.032d.mgd.msft.net ([170.133.198.14]) with mapi id 14.01.0355.003; Mon, 13 Feb 2012 14:58:38 -0600 From: "Caza, Aaron" To: "freebsd-hackers@freebsd.org" Thread-Topic: AHCI Timeouts on SATA III with Intel 520 SSDs Thread-Index: AczqkBE+uXo5uTWmSlGQ0gy+bH0uVQAAdXeQ Date: Mon, 13 Feb 2012 20:58:38 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.91.6] MIME-Version: 1.0 X-OriginatorOrg: ca.weatherford.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: AHCI Timeouts on SATA III with Intel 520 SSDs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:13:52 -0000 I've got a couple of Intel 520 SSDs that I'm running on an Intel Sandy-brid= ge based system(Core i5-2500K H67 chipset). Unfortunately, the drives expe= rience AHCI Timeouts when connected to the SATA III ports. If, however, I = connect the drives to the SATA-II ports on the same system the drives do no= t timeout. NCQ is enabled. Below is the complete dmesg showing the issue.= For my testing, I'm just using a FreeBSD 9.0 Release (amd64) generic kern= el using 'dd if=3D/dev/ada0 of=3D/dev/null bs=3D1m' to exhibit the behavior= . The drives, ofcourse, are brand new and again if I run them off the SAT= A-II ports instead of the SATA-III ports the problem goes away but then so = does the performance. Suggestions? gpart show ada0: =3D> 34 234441581 ada0 GPT (111G) 34 128 1 freebsd-boot (64k) 162 232783872 2 freebsd-ufs (111G) 232784034 1657581 - free - (809M) camcontrol identify ada0: pass0: ATA-9 SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model INTEL SSDSC2CW120A3 firmware revision 400i serial number WWN 5001517bb27d76f7 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 234441648 sectors LBA48 supported 234441648 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz (3292.59-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206a7 Family =3D 6 Model =3D 2a St= epping =3D 7 Features=3D0xbfebfbff Features2=3D0x179ae3bf AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 17179869184 (16384 MB) avail memory =3D 16459304960 (15696 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xfe000000-0xfe3ff= fff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xfe603000-0xfe6033ff irq 16= at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci3: on pcib3 xhci0: mem 0xfe500000-0xfe507fff irq 17= at device 0.0 on pci3 xhci0: 32 byte context size. usbus1 on xhci0 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 xhci1: mem 0xfe400000-0xfe407fff irq 18= at device 0.0 on pci4 xhci1: 32 byte context size. usbus2 on xhci1 pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 re0: port 0xe000-0x= e0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 19 at device 0.0 o= n pci5 re0: Using 1 MSI-X message re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000= baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto= -flow re0: Ethernet address: 80:ee:73:14:6d:b1 pcib6: irq 17 at device 28.4 on pci0 pci6: on pcib6 ehci1: mem 0xfe602000-0xfe6023ff irq 23= at device 29.0 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-= 0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xfe601000-0xfe6017ff = irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 orm0: at iomem 0xc0000-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 5.0Gbps Super Speed USB v3.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1b21> at usbus1 uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: <0x1b21> at usbus2 uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-9 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 12861691 Hz quality 1000 Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub1: 4 ports with 4 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 usbus0 ugen0.2: at usbus0 uhub4: on = usbus0 ugen3.2: at usbus3 uhub5: on = usbus3 Root mount waiting for: usbus3 usbus0 uhub4: 6 ports with 6 removable, self powered uhub5: 8 ports with 8 removable, self powered ugen3.3: at usbus3 ukbd0: on usbus3 kbd0 at ukbd0 Trying to mount root from ufs:/dev/ada0p2 [rw]... ahcich0: Timeout on slot 24 port 0 ahcich0: is 00000000 cs 06000000 ss 07000000 rs 07000000 tfd 40 serr 008800= 00 cmd 0000d817 ahcich0: Timeout on slot 21 port 0 ahcich0: is 00000000 cs 00c00000 ss 00e00000 rs 00e00000 tfd 40 serr 008800= 00 cmd 0000d517 ahcich0: Timeout on slot 28 port 0 ahcich0: is 00000000 cs e000000f ss f000000f rs f000000f tfd 40 serr 008800= 00 cmd 0000dc17 ahcich0: Timeout on slot 25 port 0 ahcich0: is 00000000 cs 00000000 ss 02000000 rs 02000000 tfd 40 serr 008800= 00 cmd 0000d917 ahcich0: Timeout on slot 16 port 0 ahcich0: is 00000000 cs 00000000 ss 00010000 rs 00010000 tfd 40 serr 008800= 00 cmd 0000d017 ahcich0: Timeout on slot 19 port 0 ahcich0: is 00000000 cs 00000000 ss 00080000 rs 00080000 tfd 40 serr 008800= 00 cmd 0000d317 ahcich0: Timeout on slot 22 port 0 ahcich0: is 00000000 cs 01800000 ss 01c00000 rs 01c00000 tfd 40 serr 008800= 00 cmd 0000d617 ahcich0: Timeout on slot 9 port 0 ahcich0: is 00000000 cs 0000fc00 ss 0000fe00 rs 0000fe00 tfd 40 serr 008800= 00 cmd 0000c917 ahcich0: Timeout on slot 17 port 0 ahcich0: is 00000000 cs 00000000 ss 00020000 rs 00020000 tfd 40 serr 008800= 00 cmd 0000d117 ahcich0: Timeout on slot 1 port 0 ahcich0: is 00000000 cs 00000000 ss 00000002 rs 00000002 tfd 40 serr 008800= 00 cmd 0000c117 ahcich0: Timeout on slot 24 port 0 ahcich0: is 00000000 cs 01000000 ss 01000000 rs 01000000 tfd c0 serr 008800= 00 cmd 0000d817 ahcich0: Timeout on slot 5 port 0 ahcich0: is 00000000 cs 00000000 ss 00000020 rs 00000020 tfd 40 serr 008800= 00 cmd 0000c517 ahcich0: Timeout on slot 8 port 0 ahcich0: is 00000000 cs 00000000 ss 00000100 rs 00000100 tfd 40 serr 008800= 00 cmd 0000c817 ahcich0: Timeout on slot 9 port 0 ahcich0: is 00000000 cs 00000000 ss 00000200 rs 00000200 tfd 40 serr 008800= 00 cmd 0000c917 ahcich0: Timeout on slot 12 port 0 ahcich0: is 00000000 cs 00000000 ss 00001000 rs 00001000 tfd 40 serr 008800= 00 cmd 0000cc17 ahcich0: Timeout on slot 26 port 0 ahcich0: is 00000000 cs 00000000 ss 04000000 rs 04000000 tfd 40 serr 008800= 00 cmd 0000da17 ahcich0: Timeout on slot 27 port 0 ahcich0: is 00000000 cs 00000000 ss 08000000 rs 08000000 tfd 40 serr 008800= 00 cmd 0000db17 ahcich0: Timeout on slot 28 port 0 ahcich0: is 00000000 cs 00000000 ss 10000000 rs 10000000 tfd 40 serr 008800= 00 cmd 0000dc17 ahcich0: Timeout on slot 4 port 0 ahcich0: is 00000000 cs 00000000 ss 00000010 rs 00000010 tfd 40 serr 008800= 00 cmd 0000c417 This message may contain confidential and privileged information. If it has= been sent to you in error, please reply to advise the sender of the error = and then immediately delete it. If you are not the intended recipient, do n= ot read, copy, disclose or otherwise use this message. The sender disclaims= any liability for such unauthorized use. PLEASE NOTE that all incoming e-m= ails sent to Weatherford e-mail accounts will be archived and may be scanne= d by us and/or by external service providers to detect and prevent threats = to our systems, investigate illegal or inappropriate behavior, and/or elimi= nate unsolicited promotional e-mails (spam). This process could result in d= eletion of a legitimate e-mail before it is read by its intended recipient = at our organization. Moreover, based on the scanning results, the full text= of e-mails and attachments may be made available to Weatherford security a= nd other personnel for review and appropriate action. If you have any conce= rns about this process, please contact us at dataprivacy@weatherford.com. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 21:38:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2C1E106564A; Mon, 13 Feb 2012 21:38:32 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1FA5D8FC08; Mon, 13 Feb 2012 21:38:32 +0000 (UTC) Received: by ggnk5 with SMTP id k5so3402558ggn.13 for ; Mon, 13 Feb 2012 13:38:31 -0800 (PST) Received: by 10.50.40.137 with SMTP id x9mr30129588igk.11.1329169111289; Mon, 13 Feb 2012 13:38:31 -0800 (PST) Received: from [72.253.42.56] ([72.253.42.56]) by mx.google.com with ESMTPS id x18sm30091736ibi.2.2012.02.13.13.38.28 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 13:38:30 -0800 (PST) Date: Mon, 13 Feb 2012 11:39:24 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alexander Motin In-Reply-To: <4F3978BC.6090608@FreeBSD.org> Message-ID: References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQlsKmQbrT2hxAkI2qN9x68yBdl04vI9AVtEhH2bMtRlGsqWIDDJDqQXfhg/6B9rITpOMzXk X-Mailman-Approved-At: Mon, 13 Feb 2012 21:58:18 +0000 Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:38:33 -0000 On Mon, 13 Feb 2012, Alexander Motin wrote: > On 02/13/12 22:23, Jeff Roberson wrote: >> On Mon, 13 Feb 2012, Alexander Motin wrote: >> >>> On 02/11/12 16:21, Alexander Motin wrote: >>>> I've heavily rewritten the patch already. So at least some of the ideas >>>> are already addressed. :) At this moment I am mostly satisfied with >>>> results and after final tests today I'll probably publish new version. >>> >>> It took more time, but finally I think I've put pieces together: >>> http://people.freebsd.org/~mav/sched.htt23.patch >> >> I need some time to read and digest this. However, at first glance, a >> global pickcpu lock will not be acceptable. Better to make a rarely >> imperfect decision than too often cause contention. > > On my tests it was opposite. Imperfect decisions under 60K MySQL requests per > second on 8 cores quite often caused two threads to be pushed to one CPU or > to one physical core, causing up to 5-10% performance penalties. I've tried > both with and without lock and at least on 8-core machine difference was > significant to add this. I understand that this is not good, but I have no > machine with hundred of CPUs to tell how will it work there. For really big > systems it could be partitioned somehow, but that will also increase load > imbalance. It would be preferable to refetch the load on the target cpu and restart the selection if it has changed. Even this should have some maximum bound on the number of times it will spin and possibly be conditionally enabled. That two cpus are making the same decision indicates that the race window is occuring and contention will be guaranteed. As you have tested on only 8 cores that's not a good sign. > >>> The patch is more complicated then previous one both logically and >>> computationally, but with growing CPU power and complexity I think we >>> can possibly spend some more time deciding how to spend time. :) >> >> It is probably worth more cycles but we need to evaluate this much more >> complex algorithm carefully to make sure that each of these new features >> provides an advantage. > > Problem is that doing half of things may not give full picture. How to do > affinity trying to save some percents, while SMT effect is times higher? Same > time too many unknown variables in applications behavior can easily make all > of this pointless. > >>> Patch formalizes several ideas of the previous code about how to >>> select CPU for running a thread and adds some new. It's main idea is >>> that I've moved from comparing raw integer queue lengths to >>> higher-resolution flexible values. That additional 8-bit precision >>> allows same time take into account many factors affecting performance. >>> Beside just choosing best from equally-loaded CPUs, with new code it >>> may even happen that because of SMT, cache affinity, etc, CPU with >>> more threads on it's queue will be reported as less loaded and opposite. >>> >>> New code takes into account such factors: >>> - SMT sharing penalty. >>> - Cache sharing penalty. >>> - Cache affinity (with separate coefficients for last-level and other >>> level caches) to the: >> >> We already used separate affinity values for different cache levels. >> Keep in mind that if something else has run on a core the cache affinity >> is lost in very short order. Trying too hard to preserve it beyond a few >> ms never seems to pan out. > > Previously it was only about timeout, that was IMHO pointless, as it is > impossible to predict when cache will be purged. It could be done in > microsecond or second later, depending on application behavior. This was not pointless. Eliminate it and see. The point is that after some time has elapsed the cache is almost certainly useless and we should select the most appropriate cpu based on load, priority, etc. We don't have perfect information for any of these algorithms. But as an approximation it is useful to know whether affinity should even be considered. An improvement on this would be to look at the amount of time the core has been idle since the selecting thread last ran rather than just the current load. Tell me what the point of selecting for affinity is if so much time has passed that valid cache contents are almost guaranteed to be lost? > >>> - other running threads of it's process, >> >> This is not really a great indicator of whether things should be >> scheduled together or not. What workload are you targeting here? > > When several threads accessing/modifying same shared memory. Like MySQL > server threads. I've noticed that on Atom CPU wit no L3 it is cheaper to move > two threads to one physical core to share the cache then handle coherency > over the memory bus. It can definitely be cheaper. But there are an equal number of cases where it will be more expensive. Some applications will have a lot of contention and shared state and these will want to be co-located. Others will simply want to get as much cache and cpu time as they can. There are a number of papers that have been published on determining which is which based on cpu performance counters. I believe sun does this in particular. Another option that apple has pursued is to give the application the option to mark threads as wanting to be close together or far away. I think the particular heuristic you have here is too expensive and specific to go in. The potential negative consequences are very big. If you want to pursue apple or sun's approach to this problem I would be interested in that. > >>> - previous CPU where it was running, >>> - current CPU (usually where it was called from). >> >> These two were also already used. Additionally: >> >> + * Hide part of the current thread >> + * load, hoping it or the scheduled >> + * one complete soon. >> + * XXX: We need more stats for this. >> >> I had something like this before. Unfortunately interactive tasks are >> allowed fairly aggressive bursts of cpu to account for things like xorg >> and web browsers. Also, I tried this for ithreads but they can be very >> expensive in some workloads so other cpus will idle as you try to >> schedule behind an ithread. > > As I have noted, this need more precise statistics about thread behavior. > Present sampled statistics is almost useless there. Existing code always > prefers to run thread on current CPU if there is no other CPU with no load. > That logic works very good when 8 MySQL threads and 8 clients working on 8 > CPUs, but a bit not so good in other situations. You're speaking of the stathz based accounting? Or you want more precise stats about other things? We've talked for years about event based accounting rather than sampling but no one has implemented it. Please go ahead if you would like. Keep in mind that cores can change frequency and tsc values may not be stable. However, even with perfect stats, I'm not sure whether ignoring the current load will be the right thing. I had some changes that took the interactivity score into account to do this. If it is very very low, then maybe it makes sense. > >>> All of these factors are configurable via sysctls, but I think >>> reasonable defaults should fit most. >>> >>> Also, comparing to previous patch, I've resurrected optimized shortcut >>> in CPU selection for the case of SMT. Comparing to original code >>> having problems with this, I've added check for other logical cores >>> load that should make it safe and still very fast when there are less >>> running threads then physical cores. >>> >>> I've tested in on Core i7 and Atom systems, but more interesting would >>> be to test it on multi-socket system with properly detected topology >>> to check benefits from affinity. >>> >>> At this moment the main issue I see is that this patch affects only >>> time when thread is starting. If thread runs continuously, it will >>> stay where it was, even if due to situation change that is not very >>> effective (causes SMT sharing, etc). I haven't looked much on periodic >>> load balancer yet, but probably it could also be somehow improved. >>> >>> What is your opinion, is it too over-engineered, or it is the right >>> way to go? >> >> I think it's a little too much change all at once. I also believe that >> the changes that try very hard to preserve affinity likely help a much >> smaller number of cases than they hurt. I would prefer you do one piece >> at a time and validate each step. There are a lot of good ideas in here >> but good ideas don't always turn into results. > > When each of these small steps can change everything and they are related, > number of combinations to test grows rapidly. I am not going to commit this > tomorrow. It is more like concept, that needs testing and evaluation. I say this because I have tried nearly all of these heuristics in different forms. I don't object to the general idea of using a weighted score to select the target cpu. However, I do think several of these heuristics are problematic. While the current algorithm is far from perfect it is the product of an incredible amount of testing and experimentation. Significant changes to it are going to require an equal amount of effort to characterize and verify. And I do believe many pieces can be broken down and tested independently. For example, whether to ignore interactive load on the core, or whether to lock pickcpu, etc. can all easily be independently tested in a number of workloads. Do you intend to clean up and commit your last, simpler patch? I have no objections to that and it simply fixes a bias in the load selection algorithm that shouldn't have existed. Thanks, Jeff > > -- > Alexander Motin > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 22:38:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF473106566B; Mon, 13 Feb 2012 22:38:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 03EBA8FC12; Mon, 13 Feb 2012 22:38:49 +0000 (UTC) Received: by eaan10 with SMTP id n10so2205637eaa.13 for ; Mon, 13 Feb 2012 14:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=z0zHdNnZnLxcOhLfLuHEEmvP85/IjSYf2McGAwAAKko=; b=q6+kM/sR+81Pmo2wt3eJetxzOY4pUUAFW6P8bOsuy7KVop63b5PkZahKF8kkQsGBb/ 0Hi+khLowFVZBp7ZDRE02XCf2qwCterMgahsdAKXsC6aNPqAV1uDhaO6t2Ib/fQ+hGZD 0xihfG+sJzUoktNWgvO0yDheTYt9dm/b7Lb7c= Received: by 10.14.13.206 with SMTP id b54mr5756203eeb.30.1329172728819; Mon, 13 Feb 2012 14:38:48 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id z47sm65801692eeh.9.2012.02.13.14.38.46 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 14:38:47 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3990EA.1080002@FreeBSD.org> Date: Tue, 14 Feb 2012 00:38:34 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 22:38:51 -0000 On 13.02.2012 23:39, Jeff Roberson wrote: > On Mon, 13 Feb 2012, Alexander Motin wrote: >> On 02/13/12 22:23, Jeff Roberson wrote: >>> On Mon, 13 Feb 2012, Alexander Motin wrote: >>> >>>> On 02/11/12 16:21, Alexander Motin wrote: >>>>> I've heavily rewritten the patch already. So at least some of the >>>>> ideas >>>>> are already addressed. :) At this moment I am mostly satisfied with >>>>> results and after final tests today I'll probably publish new version. >>>> >>>> It took more time, but finally I think I've put pieces together: >>>> http://people.freebsd.org/~mav/sched.htt23.patch >>> >>> I need some time to read and digest this. However, at first glance, a >>> global pickcpu lock will not be acceptable. Better to make a rarely >>> imperfect decision than too often cause contention. >> >> On my tests it was opposite. Imperfect decisions under 60K MySQL >> requests per second on 8 cores quite often caused two threads to be >> pushed to one CPU or to one physical core, causing up to 5-10% >> performance penalties. I've tried both with and without lock and at >> least on 8-core machine difference was significant to add this. I >> understand that this is not good, but I have no machine with hundred >> of CPUs to tell how will it work there. For really big systems it >> could be partitioned somehow, but that will also increase load imbalance. > > It would be preferable to refetch the load on the target cpu and restart > the selection if it has changed. Even this should have some maximum > bound on the number of times it will spin and possibly be conditionally > enabled. That two cpus are making the same decision indicates that the > race window is occuring and contention will be guaranteed. As you have > tested on only 8 cores that's not a good sign. Race window there exists by definition. as the code is not locked. The fact that we hitting it often may mean just that some other locks (may be in application, may be ours) cause that synchronization. Using almost equal requests in benchmark also did not increase randomness. What's about rechecking load -- that is done as you may see to protect from fast paths, as that works. But there is time window between check and putting request on the queue. Used lock doesn't fix it completely, but significantly reduce changes. >>>> The patch is more complicated then previous one both logically and >>>> computationally, but with growing CPU power and complexity I think we >>>> can possibly spend some more time deciding how to spend time. :) >>> >>> It is probably worth more cycles but we need to evaluate this much more >>> complex algorithm carefully to make sure that each of these new features >>> provides an advantage. >> >> Problem is that doing half of things may not give full picture. How to >> do affinity trying to save some percents, while SMT effect is times >> higher? Same time too many unknown variables in applications behavior >> can easily make all of this pointless. >> >>>> Patch formalizes several ideas of the previous code about how to >>>> select CPU for running a thread and adds some new. It's main idea is >>>> that I've moved from comparing raw integer queue lengths to >>>> higher-resolution flexible values. That additional 8-bit precision >>>> allows same time take into account many factors affecting performance. >>>> Beside just choosing best from equally-loaded CPUs, with new code it >>>> may even happen that because of SMT, cache affinity, etc, CPU with >>>> more threads on it's queue will be reported as less loaded and >>>> opposite. >>>> >>>> New code takes into account such factors: >>>> - SMT sharing penalty. >>>> - Cache sharing penalty. >>>> - Cache affinity (with separate coefficients for last-level and other >>>> level caches) to the: >>> >>> We already used separate affinity values for different cache levels. >>> Keep in mind that if something else has run on a core the cache affinity >>> is lost in very short order. Trying too hard to preserve it beyond a few >>> ms never seems to pan out. >> >> Previously it was only about timeout, that was IMHO pointless, as it >> is impossible to predict when cache will be purged. It could be done >> in microsecond or second later, depending on application behavior. > > This was not pointless. Eliminate it and see. The point is that after > some time has elapsed the cache is almost certainly useless and we > should select the most appropriate cpu based on load, priority, etc. We > don't have perfect information for any of these algorithms. But as an > approximation it is useful to know whether affinity should even be > considered. An improvement on this would be to look at the amount of > time the core has been idle since the selecting thread last ran rather > than just the current load. Tell me what the point of selecting for > affinity is if so much time has passed that valid cache contents are > almost guaranteed to be lost? I am not telling/going to keep affinity forever. You may see that I am also setting limit on affinity time. What's IMHO pointless is trying to set expiration time to 1/2/3ms for L1/2/3 caches. These numbers doesn't mean anything real. What I was saying is that I've differentiated affinity _force_ for the last level cache and closer levels. With "last" I don't mean L2 or L3 specifically, but last before bus/memory, that links several cores together. >>>> - other running threads of it's process, >>> >>> This is not really a great indicator of whether things should be >>> scheduled together or not. What workload are you targeting here? >> >> When several threads accessing/modifying same shared memory. Like >> MySQL server threads. I've noticed that on Atom CPU wit no L3 it is >> cheaper to move two threads to one physical core to share the cache >> then handle coherency over the memory bus. > > It can definitely be cheaper. But there are an equal number of cases > where it will be more expensive. Some applications will have a lot of > contention and shared state and these will want to be co-located. Others > will simply want to get as much cache and cpu time as they can. There > are a number of papers that have been published on determining which is > which based on cpu performance counters. I believe sun does this in > particular. Another option that apple has pursued is to give the > application the option to mark threads as wanting to be close together > or far away. > > I think the particular heuristic you have here is too expensive and > specific to go in. The potential negative consequences are very big. If > you want to pursue apple or sun's approach to this problem I would be > interested in that. I am completely agree that using performance counters here is overkill. But if applications could somehow tell us how would they like to be scheduled, that would be much more realistic. >>>> - previous CPU where it was running, >>>> - current CPU (usually where it was called from). >>> >>> These two were also already used. Additionally: >>> >>> + * Hide part of the current thread >>> + * load, hoping it or the scheduled >>> + * one complete soon. >>> + * XXX: We need more stats for this. >>> >>> I had something like this before. Unfortunately interactive tasks are >>> allowed fairly aggressive bursts of cpu to account for things like xorg >>> and web browsers. Also, I tried this for ithreads but they can be very >>> expensive in some workloads so other cpus will idle as you try to >>> schedule behind an ithread. >> >> As I have noted, this need more precise statistics about thread >> behavior. Present sampled statistics is almost useless there. Existing >> code always prefers to run thread on current CPU if there is no other >> CPU with no load. That logic works very good when 8 MySQL threads and >> 8 clients working on 8 CPUs, but a bit not so good in other situations. > > You're speaking of the stathz based accounting? Or you want more precise > stats about other things? We've talked for years about event based > accounting rather than sampling but no one has implemented it. Please go > ahead if you would like. Keep in mind that cores can change frequency > and tsc values may not be stable. Yes, I am speaking about thread run/idle times that could be improved with event-based accounting. > However, even with perfect stats, I'm not sure whether ignoring the > current load will be the right thing. I had some changes that took the > interactivity score into account to do this. If it is very very low, > then maybe it makes sense. That is what I was talking about. I was trying to avoid case when very short events push some other heavy thread into very uncomfortable position, where it will stay for a long period, while they themselves will complete in a moment. >>>> All of these factors are configurable via sysctls, but I think >>>> reasonable defaults should fit most. >>>> >>>> Also, comparing to previous patch, I've resurrected optimized shortcut >>>> in CPU selection for the case of SMT. Comparing to original code >>>> having problems with this, I've added check for other logical cores >>>> load that should make it safe and still very fast when there are less >>>> running threads then physical cores. >>>> >>>> I've tested in on Core i7 and Atom systems, but more interesting would >>>> be to test it on multi-socket system with properly detected topology >>>> to check benefits from affinity. >>>> >>>> At this moment the main issue I see is that this patch affects only >>>> time when thread is starting. If thread runs continuously, it will >>>> stay where it was, even if due to situation change that is not very >>>> effective (causes SMT sharing, etc). I haven't looked much on periodic >>>> load balancer yet, but probably it could also be somehow improved. >>>> >>>> What is your opinion, is it too over-engineered, or it is the right >>>> way to go? >>> >>> I think it's a little too much change all at once. I also believe that >>> the changes that try very hard to preserve affinity likely help a much >>> smaller number of cases than they hurt. I would prefer you do one piece >>> at a time and validate each step. There are a lot of good ideas in here >>> but good ideas don't always turn into results. >> >> When each of these small steps can change everything and they are >> related, number of combinations to test grows rapidly. I am not going >> to commit this tomorrow. It is more like concept, that needs testing >> and evaluation. > > I say this because I have tried nearly all of these heuristics in > different forms. I don't object to the general idea of using a weighted > score to select the target cpu. However, I do think several of these > heuristics are problematic. While the current algorithm is far from > perfect it is the product of an incredible amount of testing and > experimentation. Significant changes to it are going to require an equal > amount of effort to characterize and verify. And I do believe many > pieces can be broken down and tested independently. For example, whether > to ignore interactive load on the core, or whether to lock pickcpu, etc. > can all easily be independently tested in a number of workloads. > > Do you intend to clean up and commit your last, simpler patch? I have no > objections to that and it simply fixes a bias in the load selection > algorithm that shouldn't have existed. I see no much point in committing them sequentially, as they are quite orthogonal. I need to make one decision. I am going on small vacation next week. It will give time for thoughts to settle. May be I indeed just clean previous patch a bit and commit it when I get back. I've spent too much time trying to make these things formal and so far results are not bad, but also not so brilliant as I would like. May be it is indeed time to step back and try some more simple solution. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 09:45:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E6F4106564A for ; Tue, 14 Feb 2012 09:45:23 +0000 (UTC) (envelope-from pancakeking79@gmail.com) Received: from mail-lpp01m020-f182.google.com (mail-lpp01m020-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19F7E8FC19 for ; Tue, 14 Feb 2012 09:45:22 +0000 (UTC) Received: by lbbgj3 with SMTP id gj3so4360054lbb.13 for ; Tue, 14 Feb 2012 01:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=sPWcC1T6pUDtazs343ADKzS2F2Gw+5ouxJCWNdXir50=; b=NYngKDjlB8fQnbliron3li1o7FCtzNqBgRwCJw8EJ4UvUTYagGZH692ETKE+pz9ciF 6GAPodH1LV7jeW1Jg4vllSJ0Rs+5PbOQSJWBmh6wXASLPefRpCxY/K9km692uPNpB02p BPxn5kumfnF3wHPrPSepZkvM6XwTxR+fLLR7U= MIME-Version: 1.0 Received: by 10.152.147.66 with SMTP id ti2mr13622587lab.25.1329210961939; Tue, 14 Feb 2012 01:16:01 -0800 (PST) Received: by 10.152.113.68 with HTTP; Tue, 14 Feb 2012 01:16:01 -0800 (PST) Date: Tue, 14 Feb 2012 10:16:01 +0100 Message-ID: From: _ To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: quick question regarding libarchive X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 09:45:23 -0000 Hi, Have any changes been made to libarchive from FreeBSD 7.0 to 8.2 and is it possbile that these changes can report a tar.gz file corrupted when issuing gzip --test archive.tar.gz? When making my move from 7.0 to 8.2 I made backups, which when testing these on 7.0 ran fine. However, now these archives are destroyed leaving me wondering why? Thanks pancakeking79 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 14:53:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BA98106566C for ; Tue, 14 Feb 2012 14:53:45 +0000 (UTC) (envelope-from maninya@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C1BF28FC08 for ; Tue, 14 Feb 2012 14:53:44 +0000 (UTC) Received: by ghbg15 with SMTP id g15so34450ghb.13 for ; Tue, 14 Feb 2012 06:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MXtDrTc9uD717xWmK+4IPTcXaLh+CV6uyavLHY/JSvw=; b=HjJj5iQrBjL3sE4BR7H7s+oDx5YvHUD4Rk+J/m9+RBLu/GWEL0hWCqwvlvhrUA5KlW YZ85hgqlXxd6Z1aevDCQ/s33+GZi6YO/DdZiNggVagKQrHZz5A/kh2yQCSfRhYoysxss kMV5V3bsmBKTLubHAce/SBr1T615YKCWs9sJk= MIME-Version: 1.0 Received: by 10.236.124.206 with SMTP id x54mr26797526yhh.112.1329229423688; Tue, 14 Feb 2012 06:23:43 -0800 (PST) Received: by 10.146.243.17 with HTTP; Tue, 14 Feb 2012 06:23:43 -0800 (PST) Date: Tue, 14 Feb 2012 19:53:43 +0530 Message-ID: From: Maninya M To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:53:45 -0000 For multicore desktop computers, suppose one of the cores fails, the FreeBSD OS crashes. My question is about how I can make the OS tolerate this hardware fault. The strategy is to checkpoint the state of each core at specific intervals of time in main memory. Once a core fails, its previous state is retrieved from the main memory, and the processes that were running on it are rescheduled on the remaining cores. I read that the OS tolerates faults in large servers. I need to make it do this for a Desktop OS. I assume I would have to change the scheduler program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. How do I go about doing this? What exactly do I need to save for the "state" of the core? What else do I need to know? I have absolutely no experience with kernel programming or with FreeBSD. Any pointers to good sources about modifying the source-code of FreeBSD would be greatly appreciated. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 16:55:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6CB8106564A for ; Tue, 14 Feb 2012 16:55:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 99A6C8FC12 for ; Tue, 14 Feb 2012 16:55:42 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1EGteaJ098173 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 08:55:41 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3A9266.9050905@freebsd.org> Date: Tue, 14 Feb 2012 08:57:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Maninya M References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:55:46 -0000 On 2/14/12 6:23 AM, Maninya M wrote: > For multicore desktop computers, suppose one of the cores fails, the > FreeBSD OS crashes. My question is about how I can make the OS tolerate > this hardware fault. > The strategy is to checkpoint the state of each core at specific intervals > of time in main memory. Once a core fails, its previous state is retrieved > from the main memory, and the processes that were running on it are > rescheduled on the remaining cores. > > I read that the OS tolerates faults in large servers. I need to make it do > this for a Desktop OS. I assume I would have to change the scheduler > program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. > How do I go about doing this? What exactly do I need to save for the > "state" of the core? What else do I need to know? > I have absolutely no experience with kernel programming or with FreeBSD. > Any pointers to good sources about modifying the source-code of FreeBSD > would be greatly appreciated. This question has always intrigued me, because I'm always amazed that people actually try. From my viewpoint, There's really not much you can do if the core that is currently holding the scheduler lock fails. And what do you mean by 'fails"? do you run constant diagnostics? how do you tell when it is failed? It'd be hard to detect that 'multiply' has suddenly started giving bad results now and then. if it just "stops" then you might be able to have a watchdog that notices, but what do you do when it was half way through rearranging a list of items? First, you have to find out that it held the lock for the module and then you have to find out what it had done and clean up the mess. This requires rewriting many many parts of the kernel to remove 'transient inconsistent states". and even then, what do you do if it was half way through manipulating some hardware.. and when you've figured that all out, how do you cope with the mess it made because it was dying? Say for example it had started calculating bad memory offsets before writing out some stuff and written data out over random memory? but I'm interested in any answers people may have > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 17:05:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43433106564A for ; Tue, 14 Feb 2012 17:05:51 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id E93C68FC14 for ; Tue, 14 Feb 2012 17:05:50 +0000 (UTC) Received: by ghbg15 with SMTP id g15so172436ghb.13 for ; Tue, 14 Feb 2012 09:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=yG3Nr+tYYTLwVzk3Le5RdGhehzINRNMs3L7avxx6UaY=; b=yIbn3DeCFGc2OGwZcrr9kLYOGIX65YOgWoD/2np/RoXVc4GI80+b+dDLAPqmP6GBUU V0L7F1evitf4OBjZ9aUlk9pYGJeMW0Z1XlOyMx4IPULawIJ8TW5robkk8Lq56mc8xhGA U/TmHVDXTFn8Bl6era/Rneq1yiYTfo54xGpzw= Received: by 10.50.188.234 with SMTP id gd10mr5474781igc.29.1329239150069; Tue, 14 Feb 2012 09:05:50 -0800 (PST) Received: from DataIX.net (adsl-99-109-126-65.dsl.klmzmi.sbcglobal.net. [99.109.126.65]) by mx.google.com with ESMTPS id k3sm20385580igq.1.2012.02.14.09.05.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 09:05:48 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1EH5iKd062171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 12:05:44 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1EH5Yrh057087; Tue, 14 Feb 2012 12:05:34 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Tue, 14 Feb 2012 12:05:34 -0500 From: Jason Hellenthal To: Julian Elischer Message-ID: <20120214170533.GA35819@DataIX.net> References: <4F3A9266.9050905@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <4F3A9266.9050905@freebsd.org> Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:05:51 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: > On 2/14/12 6:23 AM, Maninya M wrote: > > For multicore desktop computers, suppose one of the cores fails, the > > FreeBSD OS crashes. My question is about how I can make the OS tolerate > > this hardware fault. > > The strategy is to checkpoint the state of each core at specific interv= als > > of time in main memory. Once a core fails, its previous state is retrie= ved > > from the main memory, and the processes that were running on it are > > rescheduled on the remaining cores. > > > > I read that the OS tolerates faults in large servers. I need to make it= do > > this for a Desktop OS. I assume I would have to change the scheduler > > program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. > > How do I go about doing this? What exactly do I need to save for the > > "state" of the core? What else do I need to know? > > I have absolutely no experience with kernel programming or with FreeBSD. > > Any pointers to good sources about modifying the source-code of FreeBSD > > would be greatly appreciated. > This question has always intrigued me, because I'm always amazed > that people actually try. > From my viewpoint, There's really not much you can do if the core > that is currently holding the scheduler lock fails. > And what do you mean by 'fails"? do you run constant diagnostics? > how do you tell when it is failed? It'd be hard to detect that 'multiply' > has suddenly started giving bad results now and then. >=20 > if it just "stops" then you might be able to have a watchdog that > notices, but what do you do when it was half way through rearranging > a list of items? First, you have to find out that it held > the lock for the module and then you have to find out what it had > done and clean up the mess. >=20 > This requires rewriting many many parts of the kernel to remove > 'transient inconsistent states". and even then, what do you do if it > was half way through manipulating some hardware.. >=20 > and when you've figured that all out, how do you cope with the > mess it made because it was dying? > Say for example it had started calculating bad memory offsets > before writing out some stuff and written data out over random memory? >=20 > but I'm interested in any answers people may have >=20 How about core redundancy ? effectively this would reduce the amount of available cores in half in you spread a process to run on two cores at the same time but with an option to adjust this per process etc... I don't see it as unfeasable. --=20 ;s =3D; --wac7ysb48OaltWcw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPOpRdAAoJEJBXh4mJ2FR+2qQH+QHC6q978koqM5Cilt7/9a1Q ms4mTFLqzWpy/5FXbZxlhh1xbt0HeUpfIJt1r0FZ10dkLnVYaZUTPLQCTtNTopn3 +0YmolcYkxI8OaLSQhwN7It34BNAOPmjAOvgXNuwXmRhYR+L+bezGYZ15SVbuD3D 3odgtcGp/lbVeqvD8Hm6V0Zo5Qw6z2CkbZc3Rs8bzU1WI1rUWb73x0HwrgKm0kJJ c9lT8GltiUY8ubXHlo1CqkUX+LL+WZWEtmARk+47aD1x9M/9r52T7ZlemIYvJH7K H8rhbJX6Lz3CzeGjfSgOojiV5DTza8IPJbaoFsxmtEyQAf973ohESk5fabWeFzM= =xF05 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 17:18:39 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06450106566C for ; Tue, 14 Feb 2012 17:18:39 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 788038FC22 for ; Tue, 14 Feb 2012 17:18:38 +0000 (UTC) Received: by lagz14 with SMTP id z14so257816lag.13 for ; Tue, 14 Feb 2012 09:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=+Mh/kPBhr04RrijKjN39HH5NVCHfhtfKuxKl+NXxz/I=; b=kADCn2gaobv97Q5Ug0UZ/1SouFFpU/WVkOCWtE9kmFJkTueiHLa2fUYUCNA+tAI41V aJoZ73saG8+Tvach4pwIA8vfJ3SXDvFVp3eFFtSFdMc7WQ4gk5YVlDwjzTTZz7A7hQuk JQDvmlJr0+0EoaVKLgk31xix/9a4qGpBfhnJo= Received: by 10.152.108.49 with SMTP id hh17mr15145379lab.0.1329239917229; Tue, 14 Feb 2012 09:18:37 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id mc3sm16792698lab.12.2012.02.14.09.18.33 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 09:18:35 -0800 (PST) Message-ID: <20120214.171835.987.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Tue, 14 Feb 2012 18:18:35 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20120119005658.218280@gmx.com> <4F19188A.4090907@herveybayaustralia.com.au> <4F213CEB.4020207@herveybayaustralia.com.au> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: 9.0 observations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:18:39 -0000 --------=0D=0AOpenSSH:=0D=0A--------=0D=0AAfter taking advantage of new = 'KexAlgorithms'=0D=0A# sshd -T | grep KexAlgorithms=0D=0A will never = show it ...=0D=0A=0D=0A=0D=0A-----=0D=0AWiFi:=0D=0A-----=0D=0A'media = OFDM/54Mbps' breaks setup (supplied to 'ifconfig = wlan0').=0D=0A'ucastrate' and 'mcastrate' will set it = instead.=0D=0A=0D=0A=0D=0A-----=0D=0Agpart=0D=0A-----=0D=0A=0D=0AOn a MD = vnode bassed image, of size:=0D=0A=0D=0A1g or 2g:=0D=0A # gpart create = -s MBR md0=0D=0A Will create starting offset at 63 = sector=0D=0A=3D> 63 2097089 md0 MBR (1.0G)=0D=0A=3D> 63 = 4194241 md0 MBR (2.0G)=0D=0A=0D=0A1432m:=0D=0A # gpart create -s = MBR md0=0D=0A Will create starting offset at 33 sector=0D=0A=3D> = 33 2932703 md0 MBR (1.4G)=0D=0A=0D=0A=0D=0ANOW, looking at this new = interesting alignment flag (-a 4k) ...=0D=0AI started to add slices with = it and taking into consideration BOTH above cases, all it really does = under MBR, is it takes INITIAL offset and simply STAMPS it between = slices, making NONE to align(nor to offset, nor to size =3D> = mess!):=0D=0A1g or 2g:=0D=0A 63 63 - free - = (31k)=0D=0A1432m:=0D=0A 33 33 - free - = (16k)=0D=0A=0D=0A=0D=0AHowever, with GPT, all is stable:=0D=0A# gpart = create ... always sets offset to 34, regardless of img size=0D=0AAnd (-a = 4k) properly modifies BOTH slice's 'offset' and 'size', to be divisable = with 8, without residue(=3D0)=0D=0A=0D=0AIn case:=0D=0A--=0D=0A# gpart = show -p md0=0D=0A=3D> 34 2932669 md0 GPT (1.4G)=0D=0A 34 = 1024 md0p1 freebsd-boot (512k)=0D=0A 1058 6 - = free - (3.0k)=0D=0A 1064 501760 md0p2 freebsd-ufs = (245M)=0D=0A--=0D=0A6 sectors were added in favor of aligning md0p2's = offset=0D=0AHere I have a question. Is it true that FIRST slice, should = always start at 1Mb offset (-b 1M) and why?=0D=0AShould I use (-b 1M) for = first and (-a 4k) for all other added slices?=0D=0A=0D=0A=0D=0AFinally, = taking into consideration first MBR alignment issues.=0D=0AHow should one = proceed if he wants to put MBR on 4k sector = disk?=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6=0D=0A From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 17:21:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D34B71065670 for ; Tue, 14 Feb 2012 17:21:19 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A516E8FC1C for ; Tue, 14 Feb 2012 17:21:19 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so716319pbc.13 for ; Tue, 14 Feb 2012 09:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zNyfCjlZrMHQsfAlzrtddC/BWYrfNqUuRIzVUB21gm4=; b=HPqWUWNeAzTlsaPpR7x1DyvKKDwTX0DrAoaum1j+SQ9DobOzZIxSZxy8XtpX1tU/n3 jYmY6kTmxfZgoW+a0yBO8wQFIwY0xfldPD4K9+iJH3bNL4YOVUB8ymm/jL38FPOfQgnL gS1OIqAiMWABi+w4SYraBS7w7kOy2rNLzgZZw= MIME-Version: 1.0 Received: by 10.68.229.33 with SMTP id sn1mr60395352pbc.60.1329240079263; Tue, 14 Feb 2012 09:21:19 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.131.9 with HTTP; Tue, 14 Feb 2012 09:21:19 -0800 (PST) In-Reply-To: <4F3A9266.9050905@freebsd.org> References: <4F3A9266.9050905@freebsd.org> Date: Tue, 14 Feb 2012 09:21:19 -0800 X-Google-Sender-Auth: RN5LVLeEPUTuPydYVTUfU6YI99g Message-ID: From: mdf@FreeBSD.org To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:21:19 -0000 On Tue, Feb 14, 2012 at 8:57 AM, Julian Elischer wrote= : > On 2/14/12 6:23 AM, Maninya M wrote: >> >> For multicore desktop computers, suppose one of the cores fails, the >> FreeBSD OS crashes. My question is about how I can make the OS tolerate >> this hardware fault. >> The strategy is to checkpoint the state of each core at specific interva= ls >> of time in main memory. Once a core fails, its previous state is retriev= ed >> from the main memory, and the processes that were running on it are >> rescheduled on the remaining cores. >> >> I read that the OS tolerates faults in large servers. I need to make it = do >> this for a Desktop OS. I assume I would have to change the scheduler >> program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. >> How do I go about doing this? What exactly do I need to save for the >> "state" of the core? What else do I need to know? >> I have absolutely no experience with kernel programming or with FreeBSD. >> Any pointers to good sources about modifying the source-code of FreeBSD >> would be greatly appreciated. > > This question has always intrigued me, because I'm always amazed > that people actually try. > From my viewpoint, There's really not much you can do if the core > that is currently holding the scheduler lock fails. We did this at IBM after we'd done the dynamic logical partitioning. Basically, there was a way to probe the CPU for the number of correctable errors it was encountering. At too high a threshhold, it was considered "faulty" and we offlined the CPU before it encountered an uncorrectable error. We did the same thing for memory, too (that one I was directly involved in)= . The basic trouble, though, is that at least for memory, there didn't seem to be a correlation between the rate of correctable ECC and an uncorrectable error occurring. > And what do you mean by 'fails"? =A0do you run constant diagnostics? > how do you tell when it is failed? It'd be hard to detect that 'multiply' > has suddenly started giving bad results now and then. I'd assume this is predicated by the ability of the hardware to have some redundancy and some way to query the error rate. I've done a little work with memory ECC on the device driver end, and at least there hardware definitely reports correctable and uncorrectable ECC via some registers. But I don't know if there's any way to query this for a CPU (and of course each CPU would be different). However, all that said, it's a moderately large project to get an OS ready to handle things like holes appearing in its logical CPU ID space (how do you serialize this when you want the common case to not take a lock?), and to do all the wizardry of unscheduling (what do you do with a bound thread?) and then actually shutting the CPU down via firmware so it doesn't continue running. I started working on this for Linux when I worked at IBM, somewhere around 2004, and then IBM got sued by SCO so they pulled me off the project. It was finished up by a colleague and friend. You can probably come to a first approximation by forcing e.g. the idle thread to not get switched out, when the CPU appears unstable. Then at least it's running fewer instructions, and less likely to generate a machine check. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 17:38:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F0F1065675 for ; Tue, 14 Feb 2012 17:38:47 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 11ACE8FC16 for ; Tue, 14 Feb 2012 17:38:46 +0000 (UTC) Received: by yhfs35 with SMTP id s35so198407yhf.13 for ; Tue, 14 Feb 2012 09:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Txlp/v5p8N/j5Pxb2ivIhztSEG92GvH67joB5tWqVSQ=; b=HNs1P96p7weHL0+tjscHTbCUdF8s+4eIjyoultFuhgbj63nqbeeWhC5f1DBYY4pxPI f//+FAjNct3mB/zmCk7KiSL77Ngg09VDJ8CijZPYyw/bJFwAtel87uEnxuF1G372Lggn IEA6s7Dmjgf899PPGCaxKdilyNBePKVtGentk= Received: by 10.50.217.129 with SMTP id oy1mr41385150igc.4.1329239599386; Tue, 14 Feb 2012 09:13:19 -0800 (PST) Received: from [192.168.1.3] (c-98-212-197-29.hsd1.il.comcast.net. [98.212.197.29]) by mx.google.com with ESMTPS id wn7sm20411064igc.0.2012.02.14.09.13.17 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 09:13:18 -0800 (PST) Message-ID: <4F3A9622.9010708@gmail.com> Date: Tue, 14 Feb 2012 11:13:06 -0600 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3A9266.9050905@freebsd.org> In-Reply-To: <4F3A9266.9050905@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:38:47 -0000 On 2/14/2012 10:57 AM, Julian Elischer wrote: > On 2/14/12 6:23 AM, Maninya M wrote: >> For multicore desktop computers, suppose one of the cores fails, the >> FreeBSD OS crashes. My question is about how I can make the OS tolerate >> this hardware fault. >> The strategy is to checkpoint the state of each core at specific >> intervals >> of time in main memory. Once a core fails, its previous state is >> retrieved >> from the main memory, and the processes that were running on it are >> rescheduled on the remaining cores. >> >> I read that the OS tolerates faults in large servers. I need to make >> it do >> this for a Desktop OS. I assume I would have to change the scheduler >> program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. >> How do I go about doing this? What exactly do I need to save for the >> "state" of the core? What else do I need to know? >> I have absolutely no experience with kernel programming or with FreeBSD. >> Any pointers to good sources about modifying the source-code of FreeBSD >> would be greatly appreciated. > This question has always intrigued me, because I'm always amazed > that people actually try. > From my viewpoint, There's really not much you can do if the core > that is currently holding the scheduler lock fails. > And what do you mean by 'fails"? do you run constant diagnostics? > how do you tell when it is failed? It'd be hard to detect that 'multiply' > has suddenly started giving bad results now and then. > > if it just "stops" then you might be able to have a watchdog that > notices, but what do you do when it was half way through rearranging > a list of items? First, you have to find out that it held > the lock for the module and then you have to find out what it had > done and clean up the mess. > > This requires rewriting many many parts of the kernel to remove > 'transient inconsistent states". and even then, what do you do if it > was half way through manipulating some hardware.. > > and when you've figured that all out, how do you cope with the > mess it made because it was dying? > Say for example it had started calculating bad memory offsets > before writing out some stuff and written data out over random memory? > > but I'm interested in any answers people may have > The only way I could see that it could be done, without direct hardware support, would be to virtualize it similar to how valgrind works. You'll take a speed hit bad enough to want to turn it off, but it could be possible. Testing that it works well could just mean overclocking your cpu until it starts crashing, and then seeing if it doesn't crash. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 17:41:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47DFA106564A for ; Tue, 14 Feb 2012 17:41:22 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from fireblade.netcore2k.net (fireblade.netcore2k.net [92.48.127.72]) by mx1.freebsd.org (Postfix) with ESMTP id CE83F8FC17 for ; Tue, 14 Feb 2012 17:41:21 +0000 (UTC) Received: by fireblade.netcore2k.net with ESMTP id q1EHPTwR009488 for ; Tue, 14 Feb 2012 17:25:31 GMT Message-ID: <4F3A9907.8000903@gamozo.org> Date: Tue, 14 Feb 2012 12:25:27 -0500 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3A9266.9050905@freebsd.org> <20120214170533.GA35819@DataIX.net> In-Reply-To: <20120214170533.GA35819@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:41:22 -0000 On 2/14/2012 12:05 PM, Jason Hellenthal wrote: > > On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: >> On 2/14/12 6:23 AM, Maninya M wrote: >>> For multicore desktop computers, suppose one of the cores fails, the >>> FreeBSD OS crashes. My question is about how I can make the OS tolerate >>> this hardware fault. >>> The strategy is to checkpoint the state of each core at specific intervals >>> of time in main memory. Once a core fails, its previous state is retrieved >>> from the main memory, and the processes that were running on it are >>> rescheduled on the remaining cores. >>> >>> I read that the OS tolerates faults in large servers. I need to make it do >>> this for a Desktop OS. I assume I would have to change the scheduler >>> program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. >>> How do I go about doing this? What exactly do I need to save for the >>> "state" of the core? What else do I need to know? >>> I have absolutely no experience with kernel programming or with FreeBSD. >>> Any pointers to good sources about modifying the source-code of FreeBSD >>> would be greatly appreciated. >> This question has always intrigued me, because I'm always amazed >> that people actually try. >> From my viewpoint, There's really not much you can do if the core >> that is currently holding the scheduler lock fails. >> And what do you mean by 'fails"? do you run constant diagnostics? >> how do you tell when it is failed? It'd be hard to detect that 'multiply' >> has suddenly started giving bad results now and then. >> >> if it just "stops" then you might be able to have a watchdog that >> notices, but what do you do when it was half way through rearranging >> a list of items? First, you have to find out that it held >> the lock for the module and then you have to find out what it had >> done and clean up the mess. >> >> This requires rewriting many many parts of the kernel to remove >> 'transient inconsistent states". and even then, what do you do if it >> was half way through manipulating some hardware.. >> >> and when you've figured that all out, how do you cope with the >> mess it made because it was dying? >> Say for example it had started calculating bad memory offsets >> before writing out some stuff and written data out over random memory? >> >> but I'm interested in any answers people may have >> > How about core redundancy ? effectively this would reduce the amount of > available cores in half in you spread a process to run on two cores at > the same time but with an option to adjust this per process etc... I > don't see it as unfeasable. > The overhead for all of the error checking and redundancy makes this idea pretty impractical. You'd have to have 2 cores to do the exact same thing, then some 'master' core that makes sure they're doing the right stuff, and if you really want to think about it... what if the core monitoring the cores fails... there's a threshold of when redundancy gets pointless. Perhaps I'm missing out on something, but you can't check the checker (without infinite redundancy). Honestly, if you're worried about a core failing, please take your server cluster out of the 1000 deg C forge. -Brandon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 17:49:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4EB310656D8 for ; Tue, 14 Feb 2012 17:49:41 +0000 (UTC) (envelope-from raysonlogin@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 936F08FC1B for ; Tue, 14 Feb 2012 17:49:41 +0000 (UTC) Received: by daec6 with SMTP id c6so199401dae.13 for ; Tue, 14 Feb 2012 09:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4GnzSYcz3k53jWfWCD1G9sA4QnHnGIXk2cqcxBsykjE=; b=gJG4G4h3AeeJHCJPrQf19ThkIxM9stYA7HUuI+wL27AGiZICwMLz3COvoG+SzpYtVS 4jlHZvoJiDafrq3t6XL/93G6SgTNArJROYCSK5Sw5XXaset7tzoTT1Xq/ZPJY3LTLFKa t2AGzHaOtI4zxbxcvXUFAAo7A/NDajFRFnoDo= MIME-Version: 1.0 Received: by 10.68.239.229 with SMTP id vv5mr60655942pbc.88.1329241781180; Tue, 14 Feb 2012 09:49:41 -0800 (PST) Received: by 10.142.245.14 with HTTP; Tue, 14 Feb 2012 09:49:41 -0800 (PST) Date: Tue, 14 Feb 2012 12:49:41 -0500 Message-ID: From: Rayson Ho To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: OS support for fault tolerance (re-send) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:49:41 -0000 (The email below did not show up on the online archive - resending...) ---------- Forwarded message ---------- From: Rayson Ho Date: Tue, Feb 14, 2012 at 12:27 PM Subject: Re: OS support for fault tolerance On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischer wrote: > but I'm interested in any answers people may have The way other OSes handle this is by detecting any abnormal amounts of faults (sometimes it's not the fault of the hardware - eg. when a partical from the outerspace hits a core and flips the bit), then the disable the core(s). Solaris & mainframe (z/OS) handle it this way, but you should google and find more info since I don't remember all the details. Also, see this presentation: "Getting to know the Solaris Fault Management Architecture (FMA)": http://www.prefetch.net/presentations/SolarisFaultManagement_Presentation.pdf Rayson ================================= Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.com/ > > >> _______________________________________________ >> 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 17:55:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37731106566C; Tue, 14 Feb 2012 17:55:47 +0000 (UTC) (envelope-from raysonlogin@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD538FC1B; Tue, 14 Feb 2012 17:55:46 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so747396pbc.13 for ; Tue, 14 Feb 2012 09:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TNoifQ4IpZOIj8cB+M83EH4Pm51yc4q70V7ceuI/P14=; b=FdEZ79l+HJztWD1Ah66H0omZiW5KO+YUo8HXMB4xXswzL8ixjzn8IGh+Qa23gBiFTy H8b5t/0N2FEOLZUM26OSEiGIHeJv6J60M/iJnaA171qwOr3S3WgEgtQpcWmDl51QBVXy y7/I5TrnYJSOkH43/tJSP7mo6l5LtTgF3DbI4= MIME-Version: 1.0 Received: by 10.68.132.166 with SMTP id ov6mr59924887pbb.122.1329240435872; Tue, 14 Feb 2012 09:27:15 -0800 (PST) Received: by 10.142.245.14 with HTTP; Tue, 14 Feb 2012 09:27:15 -0800 (PST) In-Reply-To: <4F3A9266.9050905@freebsd.org> References: <4F3A9266.9050905@freebsd.org> Date: Tue, 14 Feb 2012 12:27:15 -0500 Message-ID: From: Rayson Ho To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:55:47 -0000 On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischer wrote: > but I'm interested in any answers people may have The way other OSes handle this is by detecting any abnormal amounts of faults (sometimes it's not the fault of the hardware - eg. when a partical from the outerspace hits a core and flips the bit), then the disable the core(s). Solaris & mainframe (z/OS) handle it this way, but you should google and find more info since I don't remember all the details. Also, see this presentation: "Getting to know the Solaris Fault Management Architecture (FMA)": http://www.prefetch.net/presentations/SolarisFaultManagement_Presentation.pdf Rayson ================================= Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.com/ > > >> _______________________________________________ >> 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" -- Rayson ================================================== Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 18:05:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E86E41065673 for ; Tue, 14 Feb 2012 18:05:41 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 579218FC1B for ; Tue, 14 Feb 2012 18:05:41 +0000 (UTC) Received: by werm13 with SMTP id m13so212256wer.13 for ; Tue, 14 Feb 2012 10:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1+zTMppW5652MrssHsEEShwGeR3ZQhM015Asiw/RqgI=; b=TB/yPUeDD61Tf1xlGIjhsaZ18m5z423sTCJjFjESqDxQBr3RkCdrUFE0/R3Ydjo1bk Dp9dPg3mAaGBZFZ7h7N6lPyGxl58RhZNfcMLni/UGeG9UQLM9XymhUfT+rP+hElcIef7 JSb3AUTjKc6VgImF5XmgL38ETnaTADAkFiwPI= Received: by 10.216.131.78 with SMTP id l56mr1582352wei.56.1329242740194; Tue, 14 Feb 2012 10:05:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.15.90 with HTTP; Tue, 14 Feb 2012 10:05:10 -0800 (PST) In-Reply-To: <20120214170533.GA35819@DataIX.net> References: <4F3A9266.9050905@freebsd.org> <20120214170533.GA35819@DataIX.net> From: Eitan Adler Date: Tue, 14 Feb 2012 13:05:10 -0500 Message-ID: To: Jason Hellenthal Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmyHpy2PDE6ujWBGWIyhZNfDWrB6OBEC4EYCQHcQ50BfIMnEEuVTvyHdDGDBdggel7kGUws Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:05:42 -0000 On Tue, Feb 14, 2012 at 12:05 PM, Jason Hellenthal wrote: > How about core redundancy ? effectively this would reduce the amount of > available cores in half in you spread a process to run on two cores at > the same time but with an option to adjust this per process etc... I > don't see it as unfeasable. There are a number of papers discussing core redundancy. They pretty much all work the same way: process the work on two different cores (or verify some subset of the work on the second core), and wait for both cores to return prior to the commit phase. One example: www.eecs.umich.edu/~taustin/papers/MICRO32-diva.pdf Another example: www.ee.duke.edu/~sorin/papers/ieeemicro08_argus.pdf These don't use existing cores on a multi-core chip, but instead use a "functional correctness" chip but I've seen designs that use the former as well. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 18:34:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E0511065677 for ; Tue, 14 Feb 2012 18:34:50 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 356618FC13 for ; Tue, 14 Feb 2012 18:34:49 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so287805vbb.13 for ; Tue, 14 Feb 2012 10:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NBIWF/jYAsdY3pJJp9f3+HBxIKWgwjJdUTd91JPaSe8=; b=KCHXhg51bgunD7egxEHhKr7UJvpPWCKtRFpAyI9RnFKRZ3HJjPKJCS6kipwcay66oR 4DsFwwinZZtYKvUf/zw23GRYqojqFQMR95TGoX+Ao/AieJpiE9jwmdnuI3NPwyeNgRxQ xeqS2vlakhncu+LKNigV3Vo64+127rvq91Yms= MIME-Version: 1.0 Received: by 10.220.38.10 with SMTP id z10mr12468578vcd.48.1329244489485; Tue, 14 Feb 2012 10:34:49 -0800 (PST) Received: by 10.52.21.84 with HTTP; Tue, 14 Feb 2012 10:34:49 -0800 (PST) Date: Tue, 14 Feb 2012 13:34:49 -0500 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:34:50 -0000 After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 18:56:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 836361065708 for ; Tue, 14 Feb 2012 18:56:20 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 78DB08FC1E for ; Tue, 14 Feb 2012 18:56:19 +0000 (UTC) Received: (qmail 71859 invoked by uid 1004); 14 Feb 2012 18:44:19 -0000 Message-ID: <4F3AAB0C.1030404@uffe.org> Date: Tue, 14 Feb 2012 19:43:44 +0100 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3A9266.9050905@freebsd.org> <4F3A9622.9010708@gmail.com> In-Reply-To: <4F3A9622.9010708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:56:20 -0000 On 2012-02-14 18:13, Joshua Isom wrote: > On 2/14/2012 10:57 AM, Julian Elischer wrote: >> On 2/14/12 6:23 AM, Maninya M wrote: >>> For multicore desktop computers, suppose one of the cores fails, the >>> FreeBSD OS crashes. My question is about how I can make the OS tolerate >>> this hardware fault. >>> The strategy is to checkpoint the state of each core at specific >>> intervals >>> of time in main memory. Once a core fails, its previous state is >>> retrieved >>> from the main memory, and the processes that were running on it are >>> rescheduled on the remaining cores. >>> >>> I read that the OS tolerates faults in large servers. I need to make >>> it do >>> this for a Desktop OS. I assume I would have to change the scheduler >>> program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. >>> How do I go about doing this? What exactly do I need to save for the >>> "state" of the core? What else do I need to know? >>> I have absolutely no experience with kernel programming or with FreeBSD. >>> Any pointers to good sources about modifying the source-code of FreeBSD >>> would be greatly appreciated. >> This question has always intrigued me, because I'm always amazed >> that people actually try. >> From my viewpoint, There's really not much you can do if the core >> that is currently holding the scheduler lock fails. >> And what do you mean by 'fails"? do you run constant diagnostics? >> how do you tell when it is failed? It'd be hard to detect that 'multiply' >> has suddenly started giving bad results now and then. >> >> if it just "stops" then you might be able to have a watchdog that >> notices, but what do you do when it was half way through rearranging >> a list of items? First, you have to find out that it held >> the lock for the module and then you have to find out what it had >> done and clean up the mess. >> >> This requires rewriting many many parts of the kernel to remove >> 'transient inconsistent states". and even then, what do you do if it >> was half way through manipulating some hardware.. >> >> and when you've figured that all out, how do you cope with the >> mess it made because it was dying? >> Say for example it had started calculating bad memory offsets >> before writing out some stuff and written data out over random memory? >> >> but I'm interested in any answers people may have >> > > The only way I could see that it could be done, without direct hardware > support, would be to virtualize it similar to how valgrind works. You'll > take a speed hit bad enough to want to turn it off, but it could be > possible. Testing that it works well could just mean overclocking your > cpu until it starts crashing, and then seeing if it doesn't crash. > Sun/Fujitsu SPARC64 CPUs has had "mainframe class" memory mirroring, End-to-end ECC protection, register ECC and hardware instruction retry for many years now - for the exact resaons that we discuss here - fault tolerance, (high) availability etc - typically these features are called RAS (Reliability, availability and serviceability) You can read more here: http://www.fujitsu.com/global/services/computing/server/sparcenterprise/technology/availability/processor.html /Uffe From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 19:05:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7986106564A for ; Tue, 14 Feb 2012 19:05:09 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 956CC8FC18 for ; Tue, 14 Feb 2012 19:05:09 +0000 (UTC) Received: by vcmm1 with SMTP id m1so323798vcm.13 for ; Tue, 14 Feb 2012 11:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=M/lWAMOd82RatRscDKzBq5IBgKo+vXxovWDUE24Gm6U=; b=HgsayHuykPL/rGD85h9PMluOwkV1Eqo230qBciofOKP2ZscHnvQvrrkrLTOeL7nYtr M6MbK9rwvm79LEYW9XdJTxS7dVoV7pHZYoYlfEaLJr2NiuCjv/T4R9RfcJhQOgwJ/ydy Ir8tpKQmlE9sKW/wOqRRtlYWojbe7tSNCo8NI= MIME-Version: 1.0 Received: by 10.220.142.5 with SMTP id o5mr12587093vcu.68.1329246308912; Tue, 14 Feb 2012 11:05:08 -0800 (PST) Received: by 10.52.21.84 with HTTP; Tue, 14 Feb 2012 11:05:08 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 14:05:08 -0500 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:05:09 -0000 On Tue, Feb 14, 2012 at 1:34 PM, Matthew Story wrote: > After reading the man-page, and browsing around the internet for a minute, > I was just wondering if there is an option in (any) xargs to short-circuit > on first failure of [utility [arguments]]. > > e.g. > > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$&"; exit 1' worker || echo $? # cp error on my part, should not read echo exit 1, just exit 1 > 1 > 1 > > such that any non-0 exit code in a child process would cause xargs to stop > processing. seems like this would be a nice feature to have. > apologies for the copy-paste error. -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 19:05:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DA4610656D3 for ; Tue, 14 Feb 2012 19:05:52 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 26C028FC19 for ; Tue, 14 Feb 2012 19:05:51 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa01 [127.0.0.1]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with SMTP id q1EIY9nv017349; Tue, 14 Feb 2012 13:05:51 -0600 Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com with ESMTP id 12yw0dr4w5-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 13:05:51 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 13:05:17 -0600 From: Devin Teske To: "'Matthew Story'" , References: In-Reply-To: Date: Tue, 14 Feb 2012 11:05:05 -0800 Message-ID: <093b01cceb4b$9a956ba0$cfc042e0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQME1IwY3hQgsGd4pWahiNSUT3uF7JPM6CwA Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_04:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Cc: Subject: RE: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:05:52 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Matthew Story > Sent: Tuesday, February 14, 2012 10:35 AM > To: freebsd-hackers@freebsd.org > Subject: xargs short-circuit > > After reading the man-page, and browsing around the internet for a minute, > I was just wondering if there is an option in (any) xargs to short-circuit > on first failure of [utility [arguments]]. > > e.g. > > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || echo $? > 1 > 1 > > such that any non-0 exit code in a child process would cause xargs to stop > processing. seems like this would be a nice feature to have. > You can achieve this quite easily with a sub-shell: As a bourne-shell script: #!/bin/sh jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo "$*"; exit 1' worker $ARG1 || exit $? shift 1 done ) Or interactively in sh/bash: $ jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo "$*"; exit 1' worker $ARG1 || exit $?; shift 1;done ) Or interactively in csh/tcsh: % jot - 1 10 | /bin/sh -c 'while read ARG1 REST; do sh -c '\''echo "$*"; exit 1'\'' worker $ARG1 || exit $?; shift 1; done' -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 19:18:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B431065675 for ; Tue, 14 Feb 2012 19:18:29 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 94F828FC08 for ; Tue, 14 Feb 2012 19:18:29 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so330709vbb.13 for ; Tue, 14 Feb 2012 11:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cu8kkM9WxjZr07VRvDuHqeqUDVOogaWtvfbr1n6xvwI=; b=xuC1vO+7sPV1VupNZqEuAh9wR9R1LxXs91H81+0caRXhM4CwTsi2N71BHZR7z0fWNI mNMtMruOSMnkKyabQuqPOhkiSSYzewUldP04+Svc/xSer5EwLgYxFVCIEW+sjzgEoKfd OT+5dGyQEg1MXuHWlaFRrrBz9MoLDuzmjIoqo= MIME-Version: 1.0 Received: by 10.52.73.169 with SMTP id m9mr9660181vdv.95.1329247108903; Tue, 14 Feb 2012 11:18:28 -0800 (PST) Received: by 10.52.21.84 with HTTP; Tue, 14 Feb 2012 11:18:28 -0800 (PST) In-Reply-To: <093b01cceb4b$9a956ba0$cfc042e0$@fisglobal.com> References: <093b01cceb4b$9a956ba0$cfc042e0$@fisglobal.com> Date: Tue, 14 Feb 2012 14:18:28 -0500 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:18:29 -0000 On Tue, Feb 14, 2012 at 2:05 PM, Devin Teske wrote: > > > > -----Original Message----- > > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > > hackers@freebsd.org] On Behalf Of Matthew Story > > Sent: Tuesday, February 14, 2012 10:35 AM > > To: freebsd-hackers@freebsd.org > > Subject: xargs short-circuit > > > > After reading the man-page, and browsing around the internet for a > minute, > > I was just wondering if there is an option in (any) xargs to > short-circuit > > on first failure of [utility [arguments]]. > > > > e.g. > > > > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || > echo $? > > 1 > > 1 > > > > such that any non-0 exit code in a child process would cause xargs to > stop > > processing. seems like this would be a nice feature to have. > > > > You can achieve this quite easily with a sub-shell: > > As a bourne-shell script: > > #!/bin/sh > jot - 1 10 | ( while read ARG1 REST; do > sh -c 'echo "$*"; exit 1' worker $ARG1 || exit $? > shift 1 > done ) > read is often not sufficient for a variety of reasons, the most notable of them is that new-lines are valid in file names on most file systems. While some shells do support a variety of options, POSIX only supports -r (raw, treat backslashes as literal, not escape). find . -print0 | xargs -0 -e ... Is vastly nicer in most cases. Additionally, xargs provides the possibility of concurrency, via -P ... while you can spoof this with trailing & and wait(1) in sh, this is both vastly more complicated than xargs -P, and not as efficient in spawning jobs, it would be nice to be able to have xargs stop spawning new jobs on first failure in this case, and exit at last reap of existing child processes if the short-circuit flag is sent: find . -print0 | xargs -n1 -0 -e -P4 ... My use-case is a CPU-bound operation running with concurrency and many more jobs than concurrency, on failure xargs continues to work until finished to report failure, which is a large number of wasted cycles, and box load. Would be nice to bail as early as possible in situations where any failure is fatal to the larger operation. > > Or interactively in sh/bash: > > $ jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo "$*"; exit 1' worker > $ARG1 > || exit $?; shift 1;done ) > > Or interactively in csh/tcsh: > > % jot - 1 10 | /bin/sh -c 'while read ARG1 REST; do sh -c '\''echo "$*"; > exit > 1'\'' worker $ARG1 || exit $?; shift 1; done' > > -- > Devin > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 19:30:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 305A91065675 for ; Tue, 14 Feb 2012 19:30:25 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id ECA198FC19 for ; Tue, 14 Feb 2012 19:30:24 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa02 [127.0.0.1]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with SMTP id q1EJQTH9012107; Tue, 14 Feb 2012 13:30:24 -0600 Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa02.fnfis.com with ESMTP id 12yw2fg801-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 13:30:24 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 13:30:23 -0600 From: Devin Teske To: "'Matthew Story'" , References: <093b01cceb4b$9a956ba0$cfc042e0$@fisglobal.com> In-Reply-To: Date: Tue, 14 Feb 2012 11:30:28 -0800 Message-ID: <094101cceb4f$1c79cd70$556d6850$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQME1IwY3hQgsGd4pWahiNSUT3uF7AJSTotAARbuYnOTsand8A== Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_04:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Cc: Subject: RE: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:30:25 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Matthew Story > Sent: Tuesday, February 14, 2012 11:18 AM > To: freebsd-hackers@freebsd.org > Subject: Re: xargs short-circuit > > On Tue, Feb 14, 2012 at 2:05 PM, Devin Teske > wrote: > > > > > > > > -----Original Message----- > > > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > > > hackers@freebsd.org] On Behalf Of Matthew Story > > > Sent: Tuesday, February 14, 2012 10:35 AM > > > To: freebsd-hackers@freebsd.org > > > Subject: xargs short-circuit > > > > > > After reading the man-page, and browsing around the internet for a > > minute, > > > I was just wondering if there is an option in (any) xargs to > > short-circuit > > > on first failure of [utility [arguments]]. > > > > > > e.g. > > > > > > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || > > echo $? > > > 1 > > > 1 > > > > > > such that any non-0 exit code in a child process would cause xargs to > > stop > > > processing. seems like this would be a nice feature to have. > > > > > > > You can achieve this quite easily with a sub-shell: > > > > As a bourne-shell script: > > > > #!/bin/sh > > jot - 1 10 | ( while read ARG1 REST; do > > sh -c 'echo "$*"; exit 1' worker $ARG1 || exit $? > > shift 1 > > done ) > > > > read is often not sufficient for a variety of reasons, the most notable of > them is that new-lines are valid in file names on most file systems. Your original example/post neither requested nor implied that such functionality was required. If you need such functionality, then you should be using awk, perl, or some other heavier-lifting code (can even be sh(1), but you'll sacrifice speed). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 19:35:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D401065670 for ; Tue, 14 Feb 2012 19:35:32 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 452C88FC19 for ; Tue, 14 Feb 2012 19:35:32 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3D86935AD5E; Tue, 14 Feb 2012 20:35:31 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 19A7328468; Tue, 14 Feb 2012 20:35:31 +0100 (CET) Date: Tue, 14 Feb 2012 20:35:31 +0100 From: Jilles Tjoelker To: Matthew Story Message-ID: <20120214193530.GA42580@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:35:32 -0000 On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: > After reading the man-page, and browsing around the internet for a minute, > I was just wondering if there is an option in (any) xargs to short-circuit > on first failure of [utility [arguments]]. > e.g. > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || echo $? > 1 > 1 > such that any non-0 exit code in a child process would cause xargs to stop > processing. seems like this would be a nice feature to have. As per xargs(1), you can do this by having the command exit on a signal or with a value of 255. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 19:37:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA551065675 for ; Tue, 14 Feb 2012 19:37:18 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0C38FC25 for ; Tue, 14 Feb 2012 19:37:17 +0000 (UTC) Received: by vcmm1 with SMTP id m1so357323vcm.13 for ; Tue, 14 Feb 2012 11:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=osEwxuA7YYtQta9E9FgUpg+ngwlN5dTkMmhD5F19Y5c=; b=rASPSdSVOepDgupxtdeyIHxu7r5zSN2eWWyzQ0wTl8AKCZG9G2ew8itl6YA/5gUMiA p1LECLQVSYaDWfoGh9v0wJNPb+dqBSambWo4Q7bnSWgkECFoQWn2X3pcFepoIN3QEhyI p/A4KBzfjEqOCHdkWDnBKlgzPmSRVXAwif+vs= MIME-Version: 1.0 Received: by 10.52.71.226 with SMTP id y2mr9720165vdu.78.1329248237555; Tue, 14 Feb 2012 11:37:17 -0800 (PST) Received: by 10.52.21.84 with HTTP; Tue, 14 Feb 2012 11:37:17 -0800 (PST) In-Reply-To: <20120214193530.GA42580@stack.nl> References: <20120214193530.GA42580@stack.nl> Date: Tue, 14 Feb 2012 14:37:17 -0500 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:37:18 -0000 On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker wrote: > On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: > > After reading the man-page, and browsing around the internet for a > minute, > > I was just wondering if there is an option in (any) xargs to > short-circuit > > on first failure of [utility [arguments]]. > > > e.g. > > > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || > echo $? > > 1 > > 1 > > > such that any non-0 exit code in a child process would cause xargs to > stop > > processing. seems like this would be a nice feature to have. > > As per xargs(1), you can do this by having the command exit on a signal > or with a value of 255. > Yes indeed it does ... should have scoured further, thanks! > > -- > Jilles Tjoelker > -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 20:25:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F2941065670 for ; Tue, 14 Feb 2012 20:25:08 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 15EA88FC08 for ; Tue, 14 Feb 2012 20:25:07 +0000 (UTC) Received: by vcmm1 with SMTP id m1so404850vcm.13 for ; Tue, 14 Feb 2012 12:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5gYqHVl2mRwe2yfwP4BuH2aa8ktgsUI8N2qsC1mL2a0=; b=REvFuFuLrjqtT1JXvx7nFzGE9Zi/gWm80zUIETLcUnX1QjRc2Ie1tDZr7w0n2VkHX+ NqymR1yf2v/MA5hvq/VbSpdnmLMXiiuHok3DUIXIKi4EHT/5A0aI5PgB/4S60HH7wwaY C8RrpiD9RwGu8JoOqxkh6hfwzh9Kdnnbka3mE= MIME-Version: 1.0 Received: by 10.220.38.10 with SMTP id z10mr12733385vcd.48.1329251107287; Tue, 14 Feb 2012 12:25:07 -0800 (PST) Received: by 10.52.21.84 with HTTP; Tue, 14 Feb 2012 12:25:07 -0800 (PST) In-Reply-To: References: <20120214193530.GA42580@stack.nl> Date: Tue, 14 Feb 2012 15:25:07 -0500 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:25:08 -0000 On Tue, Feb 14, 2012 at 2:37 PM, Matthew Story wrote: > On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker wrote: > >> On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: >> > After reading the man-page, and browsing around the internet for a >> minute, >> > I was just wondering if there is an option in (any) xargs to >> short-circuit >> > on first failure of [utility [arguments]]. >> >> > e.g. >> >> > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || >> echo $? >> > 1 >> > 1 >> >> > such that any non-0 exit code in a child process would cause xargs to >> stop >> > processing. seems like this would be a nice feature to have. >> >> As per xargs(1), you can do this by having the command exit on a signal >> or with a value of 255. >> > exit 255 with -P, and SIGTERM (with or without -P) causes FreeBSD xargs to orphan, is this desirable behavior? findutils xargs orphans on 255 and SIGTERM (with -P), but does not orphan without -P when SIGTERM is sent. I would expect xargs to propegate the signal, or wait, although the man page does say "immediately", the POSIX specification is less clear ... this makes it more-or-less unsuitable for my needs, but i guess i could do something like: ... | xargs sh -c '... exit 255;' if [ $? -ne 0 ]; then wait # cleanup exit 1 fi > > Yes indeed it does ... should have scoured further, thanks! > > >> >> -- >> Jilles Tjoelker >> > > > > -- > regards, > matt > -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 20:52:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB11B106564A for ; Tue, 14 Feb 2012 20:52:20 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC8818FC16 for ; Tue, 14 Feb 2012 20:52:20 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so558484obc.13 for ; Tue, 14 Feb 2012 12:52:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.24.3 with SMTP id q3mr1001824oef.11.1329251330850; Tue, 14 Feb 2012 12:28:50 -0800 (PST) Received: by 10.182.116.33 with HTTP; Tue, 14 Feb 2012 12:28:50 -0800 (PST) In-Reply-To: References: <20120214193530.GA42580@stack.nl> Date: Tue, 14 Feb 2012 12:28:50 -0800 Message-ID: From: Jos Backus To: Matthew Story Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:52:21 -0000 If you're able to install a port, it has a tool called shmux which you can invoke with `-r sh', it may do what you want. Jos -- Jos Backus jos at catnook.com From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 23:00:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F5D61065688 for ; Tue, 14 Feb 2012 23:00:19 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id EE1C98FC08 for ; Tue, 14 Feb 2012 23:00:15 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1EN0EW2099811 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 15:00:15 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3AE7D9.8020204@freebsd.org> Date: Tue, 14 Feb 2012 15:01:45 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Rayson Ho References: <4F3A9266.9050905@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:00:19 -0000 On 2/14/12 9:27 AM, Rayson Ho wrote: > On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischer wrote: >> but I'm interested in any answers people may have > The way other OSes handle this is by detecting any abnormal amounts of > faults (sometimes it's not the fault of the hardware - eg. when a > partical from the outerspace hits a core and flips the bit), then the > disable the core(s). > > Solaris& mainframe (z/OS) handle it this way, but you should google > and find more info since I don't remember all the details. > > Also, see this presentation: "Getting to know the Solaris Fault > Management Architecture (FMA)": > http://www.prefetch.net/presentations/SolarisFaultManagement_Presentation.pdf True, but you can't guarantee that a cpu is going to fail in a way that you can detect like that. what if the clock just stops.. I believe that even those systems that support cpu deactivation on error only catch some percentage of the problems, and that sometimes it was more of "bring up the system without cpu X after it all crashed in flames". tandem and other systems in the old day s used to be able to cope with dying cpus pretty well but they had support from to to bottom and the software was written with 'clustering' in mind. > Rayson > > ================================= > Open Grid Scheduler / Grid Engine > http://gridscheduler.sourceforge.net/ > > Scalable Grid Engine Support Program > http://www.scalablelogic.com/ > >> >>> _______________________________________________ >>> 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" > > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 14 23:51:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B822C1065672 for ; Tue, 14 Feb 2012 23:51:31 +0000 (UTC) (envelope-from janm-freebsd-hackers@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id D46D48FC1D for ; Tue, 14 Feb 2012 23:51:30 +0000 (UTC) Received: (qmail 16502 invoked by uid 907); 14 Feb 2012 23:51:28 -0000 Received: from jmmacpro.transactionware.com (HELO jmmacpro.transactionware.com) (192.168.1.33) by midgard.transactionware.com (qpsmtpd/0.82) with ESMTP; Wed, 15 Feb 2012 10:51:28 +1100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jan Mikkelsen In-Reply-To: <4F3A9266.9050905@freebsd.org> Date: Wed, 15 Feb 2012 10:51:28 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3A9266.9050905@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1257) Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:51:31 -0000 On 15/02/2012, at 3:57 AM, Julian Elischer wrote: > On 2/14/12 6:23 AM, Maninya M wrote: >> For multicore desktop computers, suppose one of the cores fails, the >> FreeBSD OS crashes. My question is about how I can make the OS = tolerate >> this hardware fault. >> The strategy is to checkpoint the state of each core at specific = intervals >> of time in main memory. Once a core fails, its previous state is = retrieved >> from the main memory, and the processes that were running on it are >> rescheduled on the remaining cores. >>=20 >> I read that the OS tolerates faults in large servers. I need to make = it do >> this for a Desktop OS. I assume I would have to change the scheduler >> program. I am using FreeBSD 9.0 on an Intel core i5 quad core = machine. >> How do I go about doing this? What exactly do I need to save for the >> "state" of the core? What else do I need to know? >> I have absolutely no experience with kernel programming or with = FreeBSD. >> Any pointers to good sources about modifying the source-code of = FreeBSD >> would be greatly appreciated. > This question has always intrigued me, because I'm always amazed > that people actually try. > =46rom my viewpoint, There's really not much you can do if the core > that is currently holding the scheduler lock fails. > And what do you mean by 'fails"? do you run constant diagnostics? > how do you tell when it is failed? It'd be hard to detect that = 'multiply' > has suddenly started giving bad results now and then. >=20 > if it just "stops" then you might be able to have a watchdog that > notices, but what do you do when it was half way through rearranging > a list of items? First, you have to find out that it held > the lock for the module and then you have to find out what it had > done and clean up the mess. >=20 > This requires rewriting many many parts of the kernel to remove > 'transient inconsistent states". and even then, what do you do if it > was half way through manipulating some hardware.. >=20 > and when you've figured that all out, how do you cope with the > mess it made because it was dying? > Say for example it had started calculating bad memory offsets > before writing out some stuff and written data out over random memory? >=20 > but I'm interested in any answers people may have Back in the '90s I spent a bunch of time with looking at and using = systems that dealt with this kind of failure. There are two basic approaches: With software support and without. The = basic distinction is what the hardware can do when something breaks. Is = it able to continue, or must it stop immediately? Tandem had systems with both approaches: The NonStop proprietary operating system had nodes with lock-step = processors and lots of error checking that would stop immediately when = something broke. A CPU failure turned into a node halt. There was a = bunch of work to have nodes move their state around so that terminal = sessions would not be interrupted, transactions would be rolled back, = and everything would be in a consistent state. The Integrity Unix range was based on MIPS RISC/os, with a lot of work = at Tandem. We had the R2000 and later the R3000 based systems. They had = three CPUs all in lock step with voting ("triple modular redundancy"), = and entirely duplicated memory, all with ECC. Redundant busses, separate = cabinets for controllers and separate cabinets for each side of the disk = mirror. You could pull out a CPU board and memory board, show a manager, = and then plug them back in. Tandem claimed to have removed 80% of panics from the kernel, and = changed the device driver architecture so that they could recover from = some driver faults by reinitialising driver state on a running system. We still had some outages on this system, all caused by software. It was = also expensive: AUD$1,000,000 for a system with the same underlying = CPU/memory as a $30k MIPS workstation at the time. It was also slower = because of the error checking overhead. However, it did crash much less = than the MIPS boxes. Coming back to the multicore issue: The problem when a core fails is that it has affected more than its own = state. It will be holding locks on shared resources and may have = corrupted shared memory or asked a device to do the wrong thing. By the = time you detect a fault in a core, it is too late. Checkpointing to main = memory means that you need to be able to roll back to a checkpoint, and = replay operations you know about. That involves more that CPU core = state, that includes process file and device state. The Tandem lesson is that it much easier when you involve the higher = level software in dealing with these issues. Building a system where you = can make the application programmer ignorant of the need to deal with = failure is much harder than when you expose units of work to the = application programmer and can just fail a node and replay the work = somewhere else. Transactions are your friend. Lots of literature on this stuff. My favourite is "Transaction = Processing: Concepts and Techniques" (Gray & Reuter) that has a bunch of = interesting stuff. Also stuff on the underlying techniques. I can't = recall references at the moment; they're on the bookshelf at home. Regards, Jan. janm@transactionware.com From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 00:20:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353D8106564A; Wed, 15 Feb 2012 00:20:32 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id EF1A38FC15; Wed, 15 Feb 2012 00:20:31 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa03 [127.0.0.1]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with SMTP id q1ENSIeC008276; Tue, 14 Feb 2012 18:20:31 -0600 Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com with ESMTP id 1301a8g40j-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 18:20:31 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 18:20:30 -0600 From: Devin Teske To: "'Julian Elischer'" , "'Rayson Ho'" References: <4F3A9266.9050905@freebsd.org> <4F3AE7D9.8020204@freebsd.org> In-Reply-To: <4F3AE7D9.8020204@freebsd.org> Date: Tue, 14 Feb 2012 16:20:35 -0800 Message-ID: <09d201cceb77$a3f46440$ebdd2cc0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZPoW70/HD5iv4V1Tzgtg+6hIgrwFNVRxYAZCdF7oBWU3ui5WCt7aw Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_06:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Cc: 'Maninya M' , freebsd-hackers@freebsd.org Subject: RE: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 00:20:32 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Julian Elischer > Sent: Tuesday, February 14, 2012 3:02 PM > To: Rayson Ho > Cc: Maninya M; freebsd-hackers@freebsd.org > Subject: Re: OS support for fault tolerance > > On 2/14/12 9:27 AM, Rayson Ho wrote: > > On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischer wrote: > >> but I'm interested in any answers people may have > > The way other OSes handle this is by detecting any abnormal amounts of > > faults (sometimes it's not the fault of the hardware - eg. when a > > partical from the outerspace hits a core and flips the bit), then the > > disable the core(s). > > > > Solaris& mainframe (z/OS) handle it this way, but you should google > > and find more info since I don't remember all the details. > > > > Also, see this presentation: "Getting to know the Solaris Fault > > Management Architecture (FMA)": > > > http://www.prefetch.net/presentations/SolarisFaultManagement_Presentation > .pdf > True, but you can't guarantee that a cpu is going to fail in a way > that you can detect like that. > what if the clock just stops.. I believe that even those systems that > support cpu deactivation on > error only catch some percentage of the problems, and that sometimes > it was more of > "bring up the system without cpu X after it all crashed in flames". > > tandem and other systems in the old day s used to be able to cope with > dying cpus pretty well > but they had support from to to bottom and the software was written > with 'clustering' in mind. > Nowadays NEC has a their sixth-generation "Fault Tolerant (FT) Series" servers which are pretty much like the tandem servers. We got a live demo of [simulated] CPU failure and the system kept chugging along. But as Julian says, it's not guaranteed that the CPU will always fail in a predictable way (however, NEC has produced a VERY nice redundant package with 256-bit backplane to keep everything nice and lock-step). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 00:53:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD65106566B; Wed, 15 Feb 2012 00:53:39 +0000 (UTC) (envelope-from raysonlogin@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C62D8FC20; Wed, 15 Feb 2012 00:53:39 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so1078911pbc.13 for ; Tue, 14 Feb 2012 16:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xb1vhurKoAhYtcGkqYlw/N7F0USx2s5X7IkpppDs4iE=; b=uVcTfh2xGzzntnjtnNUpEW3aRkza0gHv/fSq1XwKDzag5BtLyCxdDaiII4iOikN00M H6ulSrcaXDpD0MBbsV2s1dRc7UCGvn9tAUxFyPR82TH6mMXPmuvfjv3KfxoYrcC4Iykq iMA5vU8pSPulIcEA5f8Vrl4BlNkvJ5MrhwjP8= MIME-Version: 1.0 Received: by 10.68.239.229 with SMTP id vv5mr63805842pbc.88.1329267218699; Tue, 14 Feb 2012 16:53:38 -0800 (PST) Received: by 10.142.245.14 with HTTP; Tue, 14 Feb 2012 16:53:38 -0800 (PST) In-Reply-To: <4F3AE7D9.8020204@freebsd.org> References: <4F3A9266.9050905@freebsd.org> <4F3AE7D9.8020204@freebsd.org> Date: Tue, 14 Feb 2012 19:53:38 -0500 Message-ID: From: Rayson Ho To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Maninya M Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 00:53:39 -0000 On Tue, Feb 14, 2012 at 6:01 PM, Julian Elischer wrote: > True, but you can't guarantee that a cpu is going to fail in a way that you > can detect like that. what if the clock just stops.. The question is, are we planning to handle >95% of the errors for >99% of the hardware we run on, or are we really planning to spend years trying to design something that would require special hardware support? On the zSeries mainframe, the instructions are executed in locked steps on the redundant instruction pipeline, and if the results don't match, the instruction is re-executed again. This happens on every load and store. Now, if you want software to do the same thing, you will need to somehow checkpoint the state of not only the processor, but the memory as well, or else if the bad processor stores something to memory you will still get corrupted data. Not only that the kernel becomes very complicated, it would make the system very slow. And what if the checkpointing code is executed by faulty processors?? IIRC, processors & disks don't usually just fail. That's the whole idea behind SMART, and Fault Management in Solaris & other kernels. http://hub.opensolaris.org/bin/view/Community+Group+fm/ Rayson ================================= Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.com/ > I believe that even those systems that > support cpu deactivation on > error only catch some percentage of the problems, and that sometimes it was > more of > "bring up the system without cpu X after it all crashed in flames". > > tandem and other systems in the old day s used to be able to cope with dying > cpus pretty well > but they had support from to to bottom and the software was written with > 'clustering' in mind. > > > > > > >> Rayson >> >> ================================= >> Open Grid Scheduler / Grid Engine >> http://gridscheduler.sourceforge.net/ >> >> Scalable Grid Engine Support Program >> http://www.scalablelogic.com/ >> >>> >>>> _______________________________________________ >>>> 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" >> >> >> > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 01:45:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5991D106568A for ; Wed, 15 Feb 2012 01:45:35 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9398FC15 for ; Wed, 15 Feb 2012 01:45:34 +0000 (UTC) Received: by iaeo4 with SMTP id o4so889571iae.13 for ; Tue, 14 Feb 2012 17:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dJj4X2tNbiEqGNy1Og4fOyXQJ0Iw4fGQCkJqdBKwEQE=; b=qHzqw0kehAs8tyM+3oADhYq81gbWSRAk3JTBb6Wq9yoBk7abt4Y0c9btQmVHaPLQG8 gxkLblVYm07mU2EKNtbkZ47TaUzqKV9rQIVjjcrkiAmtCIf6zaRCQTV0CzpbgFVhzeQy IweSuH6vF2UrFcSH0d+zNJD7kZZXHZa6FxlqE= Received: by 10.50.57.163 with SMTP id j3mr38878145igq.3.1329269956041; Tue, 14 Feb 2012 17:39:16 -0800 (PST) Received: from argus.electron-tube.net ([63.230.156.31]) by mx.google.com with ESMTPS id f8sm2400182ibl.6.2012.02.14.17.39.14 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 17:39:15 -0800 (PST) Message-ID: <4F3B0CC1.4050808@gmail.com> Date: Tue, 14 Feb 2012 19:39:13 -0600 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: Brandon Falk References: <4F3A9266.9050905@freebsd.org> <20120214170533.GA35819@DataIX.net> <4F3A9907.8000903@gamozo.org> In-Reply-To: <4F3A9907.8000903@gamozo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:45:35 -0000 Brandon Falk wrote: > On 2/14/2012 12:05 PM, Jason Hellenthal wrote: > >> On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: >> >>> On 2/14/12 6:23 AM, Maninya M wrote: >>> >>>> For multicore desktop computers, suppose one of the cores fails, the >>>> FreeBSD OS crashes. My question is about how I can make the OS tolerate >>>> this hardware fault. >>>> The strategy is to checkpoint the state of each core at specific intervals >>>> of time in main memory. Once a core fails, its previous state is retrieved >>>> from the main memory, and the processes that were running on it are >>>> rescheduled on the remaining cores. >>>> >>>> I read that the OS tolerates faults in large servers. I need to make it do >>>> this for a Desktop OS. I assume I would have to change the scheduler >>>> program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. >>>> How do I go about doing this? What exactly do I need to save for the >>>> "state" of the core? What else do I need to know? >>>> I have absolutely no experience with kernel programming or with FreeBSD. >>>> Any pointers to good sources about modifying the source-code of FreeBSD >>>> would be greatly appreciated. >>>> >>> This question has always intrigued me, because I'm always amazed >>> that people actually try. >>> From my viewpoint, There's really not much you can do if the core >>> that is currently holding the scheduler lock fails. >>> And what do you mean by 'fails"? do you run constant diagnostics? >>> how do you tell when it is failed? It'd be hard to detect that 'multiply' >>> has suddenly started giving bad results now and then. >>> >>> if it just "stops" then you might be able to have a watchdog that >>> notices, but what do you do when it was half way through rearranging >>> a list of items? First, you have to find out that it held >>> the lock for the module and then you have to find out what it had >>> done and clean up the mess. >>> >>> This requires rewriting many many parts of the kernel to remove >>> 'transient inconsistent states". and even then, what do you do if it >>> was half way through manipulating some hardware.. >>> >>> and when you've figured that all out, how do you cope with the >>> mess it made because it was dying? >>> Say for example it had started calculating bad memory offsets >>> before writing out some stuff and written data out over random memory? >>> >>> but I'm interested in any answers people may have >>> >>> >> How about core redundancy ? effectively this would reduce the amount of >> available cores in half in you spread a process to run on two cores at >> the same time but with an option to adjust this per process etc... I >> don't see it as unfeasable. >> >> > > The overhead for all of the error checking and redundancy makes this idea pretty > impractical. You'd have to have 2 cores to do the exact same thing, then some > 'master' core that makes sure they're doing the right stuff, and if you really > want to think about it... what if the core monitoring the cores fails... there's > a threshold of when redundancy gets pointless. > > Perhaps I'm missing out on something, but you can't check the checker (without > infinite redundancy). > > Honestly, if you're worried about a core failing, please take your server > cluster out of the 1000 deg C forge. > > -Brandon > _______________________________________________ > 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" > > Don't forget that cache would have to be redundant too. The redundant cores must not share an on-die cache. Oh, and the real biggie..... What about the chipset and busses??? Those would NOT be redundant. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 01:59:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E2BF106566C; Wed, 15 Feb 2012 01:59:31 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA0808FC17; Wed, 15 Feb 2012 01:59:30 +0000 (UTC) Received: by iaeo4 with SMTP id o4so908016iae.13 for ; Tue, 14 Feb 2012 17:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cnRk7IJtWn3lm/g+NbxV9QzKYehLBCX+G/lt1u3wFxc=; b=qPSeYR782Cxwqnes/irmkbHZVOug0+Pf4Su8kQFwWdPeDVstmvpDSMnbSR+Z+q0UUl 3I1p0GpUC7Cvle3k2/tf7JaQdY25l/3TI4s4NOiRgqZzPAg84l0DnISmLDdr3Qlk/p0t fuGqP51eLePOaTg1Kbrzlthh9xxF1aGy1Aoo4= Received: by 10.50.181.134 with SMTP id dw6mr8373065igc.11.1329269705851; Tue, 14 Feb 2012 17:35:05 -0800 (PST) Received: from argus.electron-tube.net ([63.230.156.31]) by mx.google.com with ESMTPS id mr24sm2415857ibb.1.2012.02.14.17.35.04 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 17:35:05 -0800 (PST) Message-ID: <4F3B0BC7.4010804@gmail.com> Date: Tue, 14 Feb 2012 19:35:03 -0600 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: Julian Elischer References: <4F3A9266.9050905@freebsd.org> In-Reply-To: <4F3A9266.9050905@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:59:31 -0000 Mirrored SMP? Even NonStops require a supervisory CPU subsystem to manage what is working or not. SMP itself would have to be totally rethought. My suggestion is to study the examples of NonStop and Guardian-90. Julian Elischer wrote: > On 2/14/12 6:23 AM, Maninya M wrote: >> For multicore desktop computers, suppose one of the cores fails, the >> FreeBSD OS crashes. My question is about how I can make the OS tolerate >> this hardware fault. >> The strategy is to checkpoint the state of each core at specific >> intervals >> of time in main memory. Once a core fails, its previous state is >> retrieved >> from the main memory, and the processes that were running on it are >> rescheduled on the remaining cores. >> >> I read that the OS tolerates faults in large servers. I need to make >> it do >> this for a Desktop OS. I assume I would have to change the scheduler >> program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. >> How do I go about doing this? What exactly do I need to save for the >> "state" of the core? What else do I need to know? >> I have absolutely no experience with kernel programming or with FreeBSD. >> Any pointers to good sources about modifying the source-code of FreeBSD >> would be greatly appreciated. > This question has always intrigued me, because I'm always amazed > that people actually try. > From my viewpoint, There's really not much you can do if the core > that is currently holding the scheduler lock fails. > And what do you mean by 'fails"? do you run constant diagnostics? > how do you tell when it is failed? It'd be hard to detect that 'multiply' > has suddenly started giving bad results now and then. > > if it just "stops" then you might be able to have a watchdog that > notices, but what do you do when it was half way through rearranging > a list of items? First, you have to find out that it held > the lock for the module and then you have to find out what it had > done and clean up the mess. > > This requires rewriting many many parts of the kernel to remove > 'transient inconsistent states". and even then, what do you do if it > was half way through manipulating some hardware.. > > and when you've figured that all out, how do you cope with the > mess it made because it was dying? > Say for example it had started calculating bad memory offsets > before writing out some stuff and written data out over random memory? > > but I'm interested in any answers people may have > >> _______________________________________________ >> 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" > . > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 05:41:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DE99106564A for ; Wed, 15 Feb 2012 05:41:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1B27F8FC0A for ; Wed, 15 Feb 2012 05:41:10 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1F5f7YT001256 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 21:41:10 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3B45CD.7030904@freebsd.org> Date: Tue, 14 Feb 2012 21:42:37 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Jan Mikkelsen References: <4F3A9266.9050905@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maninya M , freebsd-hackers@freebsd.org Subject: Re: OS support for fault tolerance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 05:41:11 -0000 On 2/14/12 3:51 PM, Jan Mikkelsen wrote: > > Coming back to the multicore issue: > > The problem when a core fails is that it has affected more than its own state. It will be holding locks on shared resources and may have corrupted shared memory or asked a device to do the wrong thing. By the time you detect a fault in a core, it is too late. Checkpointing to main memory means that you need to be able to roll back to a checkpoint, and replay operations you know about. That involves more that CPU core state, that includes process file and device state. > I think that/s more or less what I was saying but with more concrete examples. and yes I rememebr the tandem boxes from computer shows in Perth and Sydney, but never saw one in the field. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 10:33:27 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2D681065675 for ; Wed, 15 Feb 2012 10:33:27 +0000 (UTC) (envelope-from bvgastel@bitpowder.com) Received: from smtp10.mail.sp.isp-net.nl (smtp10.mail.sp.isp-net.nl [217.149.192.65]) by mx1.freebsd.org (Postfix) with ESMTP id 8B85C8FC0C for ; Wed, 15 Feb 2012 10:33:27 +0000 (UTC) Received: from bitpowder.com by smtp10.mail.sp.isp-net.nl via 28-53-223.ftth.xms.internl.net [85.223.53.28] with ESMTP for id q1EIPGvS022686 (8.13.2/2.04); Tue, 14 Feb 2012 19:25:16 +0100 (MET) Received: from [10.0.42.11] (localhost [127.0.0.1]) by bitpowder.com (Postfix) with ESMTPA id AEE0A18E8FD for ; Tue, 14 Feb 2012 18:25:15 +0000 (UTC) From: Bernard van Gastel Content-Type: multipart/signed; boundary="Apple-Mail=_A1EFFEDA-2AAF-4165-9F13-C572310F6928"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 14 Feb 2012 19:25:14 +0100 Message-Id: <1BDAF8C6-66A5-4F4F-A2CD-3928A0B10D48@bitpowder.com> To: hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Language-Detected: en X-Spam-Scanned: InterNLnet Mail Scan System V2.03 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: memmem small optimalisation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 10:33:28 -0000 --Apple-Mail=_A1EFFEDA-2AAF-4165-9F13-C572310F6928 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I was looking through the sources of memmove at [1], and saw a (very) = small optimization opportunity. The 'memcmp' also compares the current = character, but the current character is already checked (first part of = the condition). As we already know the size of the string is greater as = 1 (it is checked before the loop), it is possible to replace the memcmp = with (possible doing the decrease of s_len once outside the loop): memcpy(&cur[1], &cs[1], s_len-1) Am I missing something? E.g. is readability more important as speed? = This made me wonder what generally the tradeoff is that has to be taken = into account in these cases? Regards, Bernard [1] = http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/memmem.c?rev=3D1= .2 , excerpt below: for (cur =3D (char *)cl; cur <=3D last; cur++) if (cur[0] =3D=3D cs[0] && memcmp(cur, cs, s_len) =3D=3D 0) return cur; --- Bernard van Gastel Bit Powder RSS Junkie? Download the app with push notifications for Android: = https://market.android.com/details?id=3Dcom.bitpowder.rssjunkie= --Apple-Mail=_A1EFFEDA-2AAF-4165-9F13-C572310F6928-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 12:47:29 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DACAC1065673 for ; Wed, 15 Feb 2012 12:47:29 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC1F8FC18 for ; Wed, 15 Feb 2012 12:47:29 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1RxdsP-0007h5-Ml; Wed, 15 Feb 2012 14:22:25 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 00CF01CC36; Wed, 15 Feb 2012 14:22:25 +0200 (EET) Date: Wed, 15 Feb 2012 14:22:25 +0200 From: Andrey Simonenko To: Bernard van Gastel Message-ID: <20120215122225.GA34935@pm513-1.comsys.ntu-kpi.kiev.ua> References: <1BDAF8C6-66A5-4F4F-A2CD-3928A0B10D48@bitpowder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BDAF8C6-66A5-4F4F-A2CD-3928A0B10D48@bitpowder.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-02-15 14:22:25 X-Connected-IP: 10.18.52.101:15930 X-Message-Linecount: 44 X-Body-Linecount: 29 X-Message-Size: 2055 X-Body-Size: 1398 Cc: hackers@freebsd.org Subject: Re: memmem small optimalisation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:47:29 -0000 On Tue, Feb 14, 2012 at 07:25:14PM +0100, Bernard van Gastel wrote: > Hi all, > > I was looking through the sources of memmove at [1], and saw a (very) > small optimization opportunity. The 'memcmp' also compares the current > character, but the current character is already checked (first part of > the condition). As we already know the size of the string is greater as > 1 (it is checked before the loop), it is possible to replace the memcmp > with (possible doing the decrease of s_len once outside the loop): > memcpy(&cur[1], &cs[1], s_len-1) You are right, also second argument for memcpy() also can be calculated outside of the loop (remembering first character from this buffer is required). One can find similar optimization in other simple memmem() implementations. (search memmem on http://code.google.com/ for example). > Am I missing something? E.g. is readability more important as speed? > This made me wonder what generally the tradeoff is that has to be taken > into account in these cases? Looks like it will give a little improvement. If one want to use such function for huge data, then more advanced string searching algorithms are required. > [1] http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/memmem.c?rev=1.2 , excerpt below: > for (cur = (char *)cl; cur <= last; cur++) > if (cur[0] == cs[0] && memcmp(cur, cs, s_len) == 0) > return cur; From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 14:00:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28D63106566B for ; Wed, 15 Feb 2012 14:00:23 +0000 (UTC) (envelope-from kamikadze29@o2.pl) Received: from moh2-ve2.go2.pl (moh2-ve2.go2.pl [193.17.41.200]) by mx1.freebsd.org (Postfix) with ESMTP id DB0A78FC0C for ; Wed, 15 Feb 2012 14:00:22 +0000 (UTC) Received: from moh2-ve2.go2.pl (unknown [10.0.0.200]) by moh2-ve2.go2.pl (Postfix) with ESMTP id 5CE98B03BDF; Wed, 15 Feb 2012 15:00:19 +0100 (CET) Received: from o2.pl (unknown [10.0.0.17]) by moh2-ve2.go2.pl (Postfix) with SMTP; Wed, 15 Feb 2012 15:00:18 +0100 (CET) From: =?UTF-8?Q?=C5=81ukasz_Kurek?= To: =?UTF-8?Q?Andrey_Zonov?= In-Reply-To: <4F32D779.60209@zonov.org> References: <192396d2.4ca0430d.4f0baa06.40411@o2.pl> <4F32D779.60209@zonov.org> Mime-Version: 1.0 Message-ID: <195836c2.4262b373.4f3bba71.c012a@o2.pl> Date: Wed, 15 Feb 2012 15:00:17 +0100 X-Originator: 88.199.93.10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: backup BIOS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:00:23 -0000 I=20tested=20it.=20It=20really=20works.=20 Thank=20You! =C5=81ukasz=20Kurek Dnia=208=20lutego=202012=2021:13=20Andrey=20Zonov=20=20= napisa=C5=82(a): >=20On=2010.01.2012=207:01,=20=C5=81ukasz=20Kurek=20wrote: >=20>=20Hi, >=20>=20Is=20it=20possible=20to=20backup=20BIOS=20settings=20(CMOS=20conf= iguration)=20to=20file=20and=20restore=20this=20settings=20on=20the=20oth= er=20machine=20(the=20same=20hardware=20configuration=20and=20the=20same=20= BIOS)? >=20> >=20>=20I=20try=20do=20it=20for=20this=20way: >=20> >=20>=20kldload=20nvram >=20> >=20>=20dd=20if=3D/dev/nvram=20of=3Dnvram.bin=20=20=20(backup) >=20> >=20>=20dd=20if=3Dnvram.bin=20of=3D/dev/nvram=20=20=20(restore) >=20> >=20> >=20>=20but=20this=20way=20always=20load=20default=20BIOS=20settings,=20n= ot=20my=20(probably=20there=20is=20some=20kind=20of=20error). >=20 >=20Try=20sysutils/nvramtool=20instead. >=20 >=20 From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 19:08:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7BE3106566B for ; Wed, 15 Feb 2012 19:08:52 +0000 (UTC) (envelope-from ansarm@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BFD238FC14 for ; Wed, 15 Feb 2012 19:08:52 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so1910131pbc.13 for ; Wed, 15 Feb 2012 11:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RjFH6tH2sG/pgnmC2VNhKOQOaOalh8hrErniUcD6Kac=; b=RtbXR1kczfvGTulcVRad1Vtsx20IcbI/NQ+jFycpxfdo6vjANFWcaWgyEYnE3Tv39L kw1kof8CTb60vpn2LD+vGYKbKaTsnbA9l1nfmH3gyS+/7YK5HrBYFKVzEaR3TlIqA+P5 PXWJnAjigWK3ZLF3/oETqr73BfsLduPT9G2Tg= MIME-Version: 1.0 Received: by 10.68.208.136 with SMTP id me8mr6278598pbc.55.1329332932422; Wed, 15 Feb 2012 11:08:52 -0800 (PST) Received: by 10.68.23.74 with HTTP; Wed, 15 Feb 2012 11:08:52 -0800 (PST) In-Reply-To: References: <487167524.1045003.1328751695510.JavaMail.root@erie.cs.uoguelph.ca> Date: Wed, 15 Feb 2012 14:08:52 -0500 Message-ID: From: Ansar Mohammed To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Benjamin Kaduk Subject: Re: Kerberos and FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:08:53 -0000 Going back on this topic, it seems that there are alot of things that are being shipped with FreeBSD that I am not sure we need in the base distribution. Does anyone use portalfs? On Fri, Feb 10, 2012 at 3:54 AM, Ansar Mohammed wrote: > Thanks for the feedback. > I built world and disabled Kerberos in src.conf. > > I will just install Heimdal via ports now. > > There seems to be alot of other rather old bits of software in a > default installation. I noticed some old digiboard utility in a base > 9.0 build. > > On Wed, Feb 8, 2012 at 5:41 PM, Rick Macklem wrote= : >> Benjamin Kaduk wrote: >>> On Wed, 8 Feb 2012, Ansar Mohammed wrote: >>> >>> > Hello All, >>> > Is the port of Heimdal on FreeBSD being maintained? The version that >>> > ships with 9.0 seems a bit old. >>> > >>> > #> /usr/libexec/kdc-v >>> > kdc (Heimdal 1.1.0) >>> > Copyright 1995-2008 Kungliga Tekniska H=F6gskolan >>> > Send bug-reports to heimdal-bugs@h5l.org >>> >>> My understanding is that every five years or so, someone becomes fed >>> up >>> enough with the staleness of the "current" version and puts in the >>> effort >>> to merge in a newer version. >>> It looks like 3 years ago, dfr brought in that Heimdal 1.1 you see, to >>> replace the Heimdal 0.6 that nectar brought in 8 years ago. >>> I don't know of anyone with active plans to bring in a new version, at >>> present. >>> >>> -Ben Kaduk >>> >> I think it's a little trickier than it sounds. The Kerberos in FreeBSD >> isn't vanilla Heimdal 1.1, but a somewhat modified variant. >> >> Heimdal libraries have a separate source file for each function, plus >> a source file that defines all global storage used by functions in the >> library. >> One difference w.r.t. the FreeBSD variant that I am aware of is: >> - Some of the functions were moved from one library to another. (I don't >> =A0know why, but maybe it was to avoid a POLA violation which would requ= ire >> =A0apps to be linked with additional libraries?) >> =A0- To do this, some global variables were added to the source file in = the >> =A0 =A0library these functions were moved to. >> As such, if you statically link an app. to both libraries, the global va= riable >> can come up "multiply defined". (I ran into this when I was developing a= "gssd" >> prior to the one introduced as part of the kernel rpc.) You can get arou= nd this >> by dynamically linking, being careful about the order in which the libra= ries are >> specified. (The command "krb5-config --libs" helps w.r.t. this.) >> >> I don't know what else was changed, but I do know that it isn't as trivi= al as >> replacing the sources with ones from a newer Heimdal release. >> >> I think it would be nice if a newer Heimdal release was brought it, with= the >> minimal changes required to make it work. (If that meant that apps. need= ed more >> libraries, the make files could use "krb5-config --libs" to handle it, I= think?) >> >> Oh, and I'm not volunteering to try and do it;-) rick >> From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 19:28:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08A41065670 for ; Wed, 15 Feb 2012 19:28:54 +0000 (UTC) (envelope-from ansarm@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 770488FC14 for ; Wed, 15 Feb 2012 19:28:54 +0000 (UTC) Received: by daec6 with SMTP id c6so1392653dae.13 for ; Wed, 15 Feb 2012 11:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=mNNhl32Y0UcrZtGAiUD1aj9T3bZhj1h6p4D8bqDuE50=; b=Bxi9OWLS5+ga5lrXRg4izfhQgpryQ713sWR3/AJPtOmOMJkSBNHjbKpYgWW+Mpt61+ L5lfR4D+xtZbTXDqPE9UbGzN2r2KXjtJwG0UA1rLqTVr1cEv4fS+0KxL6E7ksdjQzjhi 99x0nUE3hdBbvjXmAG6g1jzD0Wyvg5y32myEg= MIME-Version: 1.0 Received: by 10.68.136.198 with SMTP id qc6mr760453pbb.160.1329334134184; Wed, 15 Feb 2012 11:28:54 -0800 (PST) Received: by 10.68.23.74 with HTTP; Wed, 15 Feb 2012 11:28:54 -0800 (PST) Date: Wed, 15 Feb 2012 14:28:54 -0500 Message-ID: From: Ansar Mohammed To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: nologin size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:28:54 -0000 Hello all, I am trying to build a minimal size FreeBSD 9 installation and I noticed that the size of nologin is almost 200k. I built FreeBSD from source so I checked the distribution, and it's also 200k. So I went back to the source and just compiled nologin.c and it came up to 5k. Can anyone explain why this executable is so large? From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 19:40:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F92106564A for ; Wed, 15 Feb 2012 19:40:55 +0000 (UTC) (envelope-from ansarm@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2308FC16 for ; Wed, 15 Feb 2012 19:40:55 +0000 (UTC) Received: by daec6 with SMTP id c6so1403972dae.13 for ; Wed, 15 Feb 2012 11:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5SJbdoTsH7B7NP/YH6c1tuXD7f96ZofOVXLguLc8ev8=; b=cfg8ktim+++WRBMNOAgdd/NB0DlBCQulrhhit2pASSxD5WkG6si348q0kyqW8wdrWD 8BeD7HrvJ9Ra698C2CuVFhT5i1+vtn1T1WoDRc2eTp99kDxmHNJUG33dcry8FpmHLhj4 lqLMknDIN5MzGPZWKNtz/TD4D6I+vkCsbo9OQ= MIME-Version: 1.0 Received: by 10.68.211.74 with SMTP id na10mr1080853pbc.76.1329334854922; Wed, 15 Feb 2012 11:40:54 -0800 (PST) Received: by 10.68.23.74 with HTTP; Wed, 15 Feb 2012 11:40:54 -0800 (PST) In-Reply-To: <4f3c09d8.c922e50a.46ef.1eb1SMTPIN_ADDED@mx.google.com> References: <4f3c09d8.c922e50a.46ef.1eb1SMTPIN_ADDED@mx.google.com> Date: Wed, 15 Feb 2012 14:40:54 -0500 Message-ID: From: Ansar Mohammed To: Simon Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" Subject: Re: nologin size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:40:55 -0000 You are right. Fast catch :) On Wed, Feb 15, 2012 at 2:39 PM, Simon wrote: > > Haven't checked into it, but quick guess static vs dynamic, stripped vs not > stripped, > check those first. You have likely compiled dynamic nologin. > > -Simon > > > On Wed, 15 Feb 2012 14:28:54 -0500, Ansar Mohammed wrote: > >>Hello all, >>I am trying to build a minimal size FreeBSD 9 installation and I >>noticed that the size of nologin is almost 200k. >>I built FreeBSD from source so I checked the distribution, and it's also >> 200k. >>So I went back to the source and just compiled nologin.c and it came up to >> 5k. >> >>Can anyone explain why this executable is so large? >>_______________________________________________ >>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 Feb 15 19:41:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 600891065670 for ; Wed, 15 Feb 2012 19:41:46 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 29BFA8FC1A for ; Wed, 15 Feb 2012 19:41:45 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa02 [127.0.0.1]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with SMTP id q1FJRARn022425; Wed, 15 Feb 2012 13:41:45 -0600 Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com with ESMTP id 130j8gr6pd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Feb 2012 13:41:45 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 13:41:44 -0600 From: Devin Teske To: "'Ansar Mohammed'" , References: In-Reply-To: Date: Wed, 15 Feb 2012 11:41:52 -0800 Message-ID: <0a7601ccec19$de715a90$9b540fb0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE+9AuCztIL1YQbCDOUpC5H/ta/IJdaSp4g Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-15_05:2012-02-15, 2012-02-15, 1970-01-01 signatures=0 Cc: Subject: RE: nologin size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:41:46 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Ansar Mohammed > Sent: Wednesday, February 15, 2012 11:29 AM > To: freebsd-hackers@freebsd.org > Subject: nologin size > > Hello all, > I am trying to build a minimal size FreeBSD 9 installation and I > noticed that the size of nologin is almost 200k. > I built FreeBSD from source so I checked the distribution, and it's also 200k. > So I went back to the source and just compiled nologin.c and it came up to 5k. > > Can anyone explain why this executable is so large? Dynamic versus static executable. 200K version: % ldd /usr/sbin/nologin ldd: /usr/sbin/nologin: not a dynamic ELF executable 5K version (produced manually by compiling/linking oneself -- shown below): % cd /usr/src/usr.sbin/nologin % sudo cc -c nologin.c -o nologin.o % sudo cc -g nologin.o -o nologin % ldd nologin nologin: libc.so.7 => /lib/libc.so.7 (0x28090000) -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 19:47:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36CA21065672; Wed, 15 Feb 2012 19:47:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3C18FC1F; Wed, 15 Feb 2012 19:47:10 +0000 (UTC) Received: by eaan10 with SMTP id n10so549282eaa.13 for ; Wed, 15 Feb 2012 11:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6WDMiL0/02bXkG2RMrMLDOdEIxH8Xj/lGKEnsHN7ipU=; b=gDkagUmno/A9rkmWjNosloo1jY5O4X4S/pigvFinhPiAHbYelyYYsagQzMGShcKGzn JeeqcG0+nN1KD1GdpTftLRETIeRnboX7vnInKDZu/2+na0QGLyQmToaWK3JRhq2bvH7Z T6TgowWXvmufsoZUXu2yQxcS2btRn6cVUAuso= Received: by 10.213.13.80 with SMTP id b16mr1505983eba.146.1329335229268; Wed, 15 Feb 2012 11:47:09 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id y12sm14305168eeb.11.2012.02.15.11.47.06 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 11:47:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3C0BB9.6050101@FreeBSD.org> Date: Wed, 15 Feb 2012 21:47:05 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> In-Reply-To: <4F3990EA.1080002@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:47:11 -0000 On 02/14/12 00:38, Alexander Motin wrote: > I see no much point in committing them sequentially, as they are quite > orthogonal. I need to make one decision. I am going on small vacation > next week. It will give time for thoughts to settle. May be I indeed > just clean previous patch a bit and commit it when I get back. I've > spent too much time trying to make these things formal and so far > results are not bad, but also not so brilliant as I would like. May be > it is indeed time to step back and try some more simple solution. I've decided to stop those cache black magic practices and focus on things that really exist in this world -- SMT and CPU load. I've dropped most of cache related things from the patch and made the rest of things more strict and predictable: http://people.freebsd.org/~mav/sched.htt34.patch This patch adds check to skip fast previous CPU selection if it's SMT neighbor is in use, not just if no SMT present as in previous patches. I've took affinity/preference algorithm from the first patch and improved it. That makes pickcpu() to prefer previous core or it's neighbors in case of equal load. That is very simple to keep it, but still should give cache hits. I've changed the general algorithm of topology tree processing. First I am looking for idle core on the same last-level cache as before, with affinity to previous core or it's neighbors on higher level caches. Original code could put additional thread on already busy core, while next socket is completely idle. Now if there is no idle core on this cache, then all other CPUs are checked. CPU groups comparison now done in two steps: first, same as before, compared summary load of all cores; but now, if it is equal, I am comparing load of the less/most loaded cores. That should allow to differentiate whether load 2 really means 1+1 or 2+0. In that case group with 2+0 will be taken as more loaded than one with 1+1, making group choice more grounded and predictable. I've added randomization in case if all above factors are equal. As before I've tested this on Core i7-870 with 4 physical and 8 logical cores and Atom D525 with 2 physical and 4 logical cores. On Core i7 I've got speedup up to 10-15% in super-smack MySQL and PostgreSQL indexed select for 2-8 threads and no penalty in other cases. pbzip2 shows up to 13% performance increase for 2-5 threads and no penalty in other cases. Tests on Atom show mostly about the same performance as before in database benchmarks: faster for 1 thread, slower for 2-3 and about the same for other cases. Single stream network performance improved same as for the first patch. That CPU is quite difficult to handle as with mix of effective SMT and lack of L3 cache different scheduling approaches give different results in different situations. Specific performance numbers can be found here: http://people.freebsd.org/~mav/bench.ods Every point there includes at least 5 samples and except pbzip2 test that is quite unstable with previous sources all are statistically valid. Florian is now running alternative set of benchmarks on dual-socket hardware without SMT. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 20:00:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FAC61065672 for ; Wed, 15 Feb 2012 20:00:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4DE8FC1A for ; Wed, 15 Feb 2012 20:00:20 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 9317C54D3; Wed, 15 Feb 2012 12:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1329336020; bh=rpZlbr/Vjl6NLCER9dez367AipKJWmT1FZjkVw+IYA8=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=4qgOLJ7mV2Z0CUZaKhEnI+J1xPPO9NoiTyO377GyKctSzRzKt/bYhsXPaPnL8Frk1 x3cAWjZSgOV16uRVUGVprF8bMFqVsW7YFhh/UswPc/2/ovhhFbvfdqHojLAY9yr+8X hRa3BidpUi5FTDMgbsnMMPa16gmyOxC0roCmpltQ= Message-ID: <4F3C0ED1.9010004@delphij.net> Date: Wed, 15 Feb 2012 12:00:17 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Ansar Mohammed References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, d@delphij.net Subject: Re: nologin size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:00:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/15/12 11:28, Ansar Mohammed wrote: > Hello all, I am trying to build a minimal size FreeBSD 9 > installation and I noticed that the size of nologin is almost > 200k. I built FreeBSD from source so I checked the distribution, > and it's also 200k. So I went back to the source and just compiled > nologin.c and it came up to 5k. The Makefile have described why it's statically linked: # It is important that nologin be statically linked for security # reasons. A dynamic non-setuid binary can be linked against a trojan # libc by setting LD_LIBRARY_PATH appropriately. Both sshd(8) and # login(1) make it possible to log in with an unsanitized environment, # rendering a dynamic nologin binary virtually useless. NO_SHARED= YES Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEbBAEBCAAGBQJPPA7RAAoJEG80Jeu8UPuz2k0H8wbyLWS6+V0ebKJzPtB1BZzP o6VWo6sXrG5sMb7kegQdtouYjjfCh1XGxj8jT/nCdOcmXFTvta4GaEnwNZjT3IJp bhIRU3sh7G3AOs9WjXlDhwyPCuLp3LdWPu6/4kjdME3VZp6YQRn6SSHtS/OAG/nS HJtlee64Udlkj1OVIPKENpdSdv4dzJt5afSsK0Ju9HH+vrpFKv5fwUWcXVCFya4R iPiU+hDlVUG0ivjK7Aa12rKavrJxmuC6am7KansLF9LsjTHm8zBxswPgJwVEXO9v xIoFHnbfUHLi9r/NAUICudpPmoNfp8M8MNei+n2KQwPK4FsHdiIGcIkfQCsrJQ== =4yw1 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 20:05:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9386B106564A for ; Wed, 15 Feb 2012 20:05:45 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 3357C8FC1B for ; Wed, 15 Feb 2012 20:05:45 +0000 (UTC) Received: (qmail 60425 invoked by uid 110); 15 Feb 2012 19:39:03 -0000 Received: from unknown (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 15 Feb 2012 19:39:03 -0000 From: "Simon" To: "Ansar Mohammed" , "freebsd-hackers@freebsd.org" Date: Wed, 15 Feb 2012 14:39:07 -0500 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120215200545.9386B106564A@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: nologin size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:05:45 -0000 Haven't checked into it, but quick guess static vs dynamic, stripped vs not stripped, check those first. You have likely compiled dynamic nologin. -Simon On Wed, 15 Feb 2012 14:28:54 -0500, Ansar Mohammed wrote: >Hello all, >I am trying to build a minimal size FreeBSD 9 installation and I >noticed that the size of nologin is almost 200k. >I built FreeBSD from source so I checked the distribution, and it's also 200k. >So I went back to the source and just compiled nologin.c and it came up to 5k. >Can anyone explain why this executable is so large? >_______________________________________________ >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 Feb 15 20:06:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1832F106566C; Wed, 15 Feb 2012 20:06:39 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4E46F8FC16; Wed, 15 Feb 2012 20:06:38 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so1188654wib.13 for ; Wed, 15 Feb 2012 12:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A0ZI7P3pepifISsi73sLfYBXK8QqJ8SDXdplwMaS+Q8=; b=YjcfXSEkYItCB5WCtTwU3OvpiUHkTixpHRXvJpCzXqUKLlCIc8qDip4vdKVzQ5wS1u HgSX0EuiyyaM9i/DdT4SaclXfu/2Y+SrEZxsapdRXDAQEqZJpsDZazY4U3NtHo+wSt2K YcIdRmYRAj3uzmiPQi42MBauzejapDJGl4vWA= Received: by 10.216.137.88 with SMTP id x66mr12292980wei.8.1329336397518; Wed, 15 Feb 2012 12:06:37 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n5sm15175897wiw.7.2012.02.15.12.06.35 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 12:06:36 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3C104A.4020805@FreeBSD.org> Date: Wed, 15 Feb 2012 22:06:34 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:06:39 -0000 On 02/15/12 21:54, Jeff Roberson wrote: > On Wed, 15 Feb 2012, Alexander Motin wrote: >> As before I've tested this on Core i7-870 with 4 physical and 8 >> logical cores and Atom D525 with 2 physical and 4 logical cores. On >> Core i7 I've got speedup up to 10-15% in super-smack MySQL and >> PostgreSQL indexed select for 2-8 threads and no penalty in other >> cases. pbzip2 shows up to 13% performance increase for 2-5 threads and >> no penalty in other cases. > > Can you also test buildworld or buildkernel with a -j value twice the > number of cores? This is an interesting case because it gets little > benefit from from affinity and really wants the best balancing possible. > It's also the first thing people will complain about if it slows. I'll do it, but even now I can say that existing balancing algorithm requires improvements to better handle SMT. If I understand correctly, present code never takes the last running thread from it's CPU. It is fine for non-SMT systems, but with SMT it may cause imbalance and as result reduced total performance. While current pickcpu() algorithm should be precise enough, its decision can be easily affected by some microsecond transient load, such as interrupt threads, etc, and results of that decision may be effective for seconds. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 19:53:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12828106566B; Wed, 15 Feb 2012 19:53:54 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2A0D8FC13; Wed, 15 Feb 2012 19:53:53 +0000 (UTC) Received: by iaeo4 with SMTP id o4so2419366iae.13 for ; Wed, 15 Feb 2012 11:53:53 -0800 (PST) Received: by 10.50.159.161 with SMTP id xd1mr14088449igb.15.1329335633210; Wed, 15 Feb 2012 11:53:53 -0800 (PST) Received: from [72.253.42.56] ([72.253.42.56]) by mx.google.com with ESMTPS id wn7sm26472538igc.0.2012.02.15.11.53.51 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 11:53:52 -0800 (PST) Date: Wed, 15 Feb 2012 09:54:46 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alexander Motin In-Reply-To: <4F3C0BB9.6050101@FreeBSD.org> Message-ID: References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQkZ47a4ndSzpn6+5kPQRgYfLCNY+dMM64S9Moagy4Ru9sl+SHkbgJ9Op/0WlyGOakYFkhRz X-Mailman-Approved-At: Wed, 15 Feb 2012 21:42:35 +0000 Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:53:54 -0000 On Wed, 15 Feb 2012, Alexander Motin wrote: > On 02/14/12 00:38, Alexander Motin wrote: >> I see no much point in committing them sequentially, as they are quite >> orthogonal. I need to make one decision. I am going on small vacation >> next week. It will give time for thoughts to settle. May be I indeed >> just clean previous patch a bit and commit it when I get back. I've >> spent too much time trying to make these things formal and so far >> results are not bad, but also not so brilliant as I would like. May be >> it is indeed time to step back and try some more simple solution. > > I've decided to stop those cache black magic practices and focus on things > that really exist in this world -- SMT and CPU load. I've dropped most of > cache related things from the patch and made the rest of things more strict > and predictable: > http://people.freebsd.org/~mav/sched.htt34.patch This looks great. I think there is value in considering the other approach further but I would like to do this part first. It would be nice to also add priority as a greater influence in the load balancing as well. > > This patch adds check to skip fast previous CPU selection if it's SMT > neighbor is in use, not just if no SMT present as in previous patches. > > I've took affinity/preference algorithm from the first patch and improved it. > That makes pickcpu() to prefer previous core or it's neighbors in case of > equal load. That is very simple to keep it, but still should give cache hits. > > I've changed the general algorithm of topology tree processing. First I am > looking for idle core on the same last-level cache as before, with affinity > to previous core or it's neighbors on higher level caches. Original code > could put additional thread on already busy core, while next socket is > completely idle. Now if there is no idle core on this cache, then all other > CPUs are checked. > > CPU groups comparison now done in two steps: first, same as before, compared > summary load of all cores; but now, if it is equal, I am comparing load of > the less/most loaded cores. That should allow to differentiate whether load 2 > really means 1+1 or 2+0. In that case group with 2+0 will be taken as more > loaded than one with 1+1, making group choice more grounded and predictable. > > I've added randomization in case if all above factors are equal. This all sounds good. I will need to review in detail but the approach seems straightforward and fixes corner cases that are undesirable. > > As before I've tested this on Core i7-870 with 4 physical and 8 logical cores > and Atom D525 with 2 physical and 4 logical cores. On Core i7 I've got > speedup up to 10-15% in super-smack MySQL and PostgreSQL indexed select for > 2-8 threads and no penalty in other cases. pbzip2 shows up to 13% performance > increase for 2-5 threads and no penalty in other cases. Can you also test buildworld or buildkernel with a -j value twice the number of cores? This is an interesting case because it gets little benefit from from affinity and really wants the best balancing possible. It's also the first thing people will complain about if it slows. > > Tests on Atom show mostly about the same performance as before in database > benchmarks: faster for 1 thread, slower for 2-3 and about the same for other > cases. Single stream network performance improved same as for the first > patch. That CPU is quite difficult to handle as with mix of effective SMT and > lack of L3 cache different scheduling approaches give different results in > different situations. > > Specific performance numbers can be found here: > http://people.freebsd.org/~mav/bench.ods > Every point there includes at least 5 samples and except pbzip2 test that is > quite unstable with previous sources all are statistically valid. > > Florian is now running alternative set of benchmarks on dual-socket hardware > without SMT. Again, thank you very much for working on this. Jeff > > -- > Alexander Motin > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 15 22:11:51 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87276106566B for ; Wed, 15 Feb 2012 22:11:51 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 39F8E8FC0A for ; Wed, 15 Feb 2012 22:11:50 +0000 (UTC) Received: (qmail 6069 invoked from network); 15 Feb 2012 16:45:10 -0500 Received: from c-76-119-101-151.hsd1.ma.comcast.net (HELO ?192.168.1.6?) (76.119.101.151) by mail.atlantawebhost.com with SMTP; 15 Feb 2012 16:45:10 -0500 Message-ID: <4F3C275F.9070808@shadowsun.net> Date: Wed, 15 Feb 2012 16:45:03 -0500 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120214 Thunderbird/10.0.1 MIME-Version: 1.0 To: hackers@freebsd.org, freebsd-ports@freebsd.org X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig452D75C8B6F77C657F433B51" Cc: Subject: CUDA porting effort? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:11:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig452D75C8B6F77C657F433B51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given that NVidia is releasing the CUDA platform source on a limited basis, is anyone actively working to port it to FreeBSD? The reason I ask is that to get access to the source, you have to submit a request explaining what you intend to use it for. It might be a good idea to get ahold of the source on behalf of FreeBSD, so that interested people could work on porting it. I could devote a small amount of time to such an effort; I'm wondering if there's interest from anyone else. --------------enig452D75C8B6F77C657F433B51 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJPPCdlAAoJENSCzbQ+koZ75qgQAMRUeeQP2bo1GAMQVN29itVt vpmOl0yghH+Zo8A5LY+3/6jdFfz+SfZPBw9v1m1Yi2n2j6wlYAWsSfUPcQevnmQW BgcXfJnHk+7vJUGyaFX1SeCyKjvGrRxIRTPwHTZoi3UPK02aIReU/CLQwMk9m/v/ NpQoZv1MMF4g0SwmrAOwWl6CFDzODycTr3pvIhnGQdSIk4buKlHlY++623+FLzMf cRn1rXnvQjg/fYs9hjfnVveaGNJROlosa1cwCGWsXPfQaAoiUx9clkuAPsyVJOgE L794bAOGO8XDUZp1OxFevwOqGSEnllVArKffWnZjKHbgjvM7t7RQ5WBmT7p5gUPk BjhZbNNqBCIYdrwYqNVNk89bVLP00yRtiqQOj3o45fAbbvRIgwnu797PBqYygGLW NLWU+NkRHQkeaLB3EBcR+LD2IW+DDcFpc9AFxqPusPhENq+Rheyub/0yx4LlEOaV KspReQlhj2+HX9RQ86cUJrYxDo2XVcWuFS2k8SYBwuyFpyytdhliwFw1cdcZZcLB BvD4PwIZzOIoE1ECVDkm6m9ATmrhPaDl2ewb9kiY2F8ivYyGGxZs/jsMhLestPUU inbTDuN1B8wMP8Rn5/YMh1E/eqSEKHNl4V1B9x265FEMj3/ZTjD6lo8KsephCDOf KR85XbqnB71eAFibp0+G =c5SD -----END PGP SIGNATURE----- --------------enig452D75C8B6F77C657F433B51-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 03:43:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF2DA1065672; Thu, 16 Feb 2012 03:43:54 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFCD8FC18; Thu, 16 Feb 2012 03:43:54 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so1781504vbb.13 for ; Wed, 15 Feb 2012 19:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xTIMqZ5Kybd4h9wRK2S16jDh2VdYlzRsh8yrJTX2Qfg=; b=UCQKsxe054jat1AMbm7gRE5OWcdB/+S7wviLFm1Ky+dRFRt4bL9d1B1uZXNF/GzTLl PuvSXtGuDZI3aAr2K3yJsbljulWs6IdgOvq4O89AIB4zjszs10a2/0f8hWYJSAQJ0b8z x3eOdPyIv+Snj95FHY+Kh7g5kJHa9Zz6cUNr8= MIME-Version: 1.0 Received: by 10.52.34.4 with SMTP id v4mr283921vdi.85.1329362435240; Wed, 15 Feb 2012 19:20:35 -0800 (PST) Received: by 10.220.179.131 with HTTP; Wed, 15 Feb 2012 19:20:35 -0800 (PST) In-Reply-To: <201111081005.43851.jhb@freebsd.org> References: <201111081005.43851.jhb@freebsd.org> Date: Wed, 15 Feb 2012 19:20:35 -0800 Message-ID: From: Vijay Singh To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 03:43:54 -0000 Hi John, >> (kgdb-amd64-6.8-71) f 5 >> #5 =A00xffffffff803b73e6 in softclock (arg=3D0xffffffff80c90f40) at >> ../../../../sys/kern/kern_timeout.c:461 >> 461 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 class->lc_unlock(c_lock); >> (kgdb-amd64-6.8-71) l >> 456 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 lastfunc =3D c_func; >> 457 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = } >> 458 =A0 #endif >> 459 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = CTR1(KTR_CALLOUT, "callout %p finished", c); >> 460 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = if ((c_flags & CALLOUT_RETURNUNLOCKED) =3D=3D 0) >> 461 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 class->lc_unlock(c_lock); >> 462 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 skip: >> 463 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = CC_LOCK(cc); >> 464 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = /* >> 465 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0* If the current callout is locally >> (kgdb-amd64-6.8-71) i local >> c_func =3D (void (*)(void *)) 0xffffffff8060d550 > > You'll need to see if there is a way that this routine can drop the lock.= =A0If > you can reproduce this panic easily, then perhaps try building with KTR a= nd > KTR_LOCK traces enabled and use 'show ktr' in ddb to see when this thread > dropped Giant. An update. I haven't been able to enable KTR in my environment. However I found some interesting. In the code below: (kgdb-amd64-6.8-48) l 402 if (c_lock !=3D NULL) { 403 if (c_lock =3D=3D &Giant.lock_object) { 404 mtx_lock(&Giant); 405 mtx_assert(&Giant, MA_OWNED); 406 } else { 407 class->lc_lock(c_lock, sharedlock); 408 } I hit the assert in line 405. So right after locking Giant, it is found unlocked!!! Everytime this hits, I see that kldload is running on the other CPU: (kgdb-amd64-6.8-48) show_ps_running CPU ticks pri thread tid pid state VSZ RSS cmd 0 2 52 0xffffff000424c800 100006 11 TDS_RUNNING 0K 0K [intr] 1 3 76 0xffffff0004618400 100065 1481 TDS_RUNNING 3808K 760K kldload Reporting it here to see if someone has seen this before. -vijay From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 04:30:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82D011065677 for ; Thu, 16 Feb 2012 04:30:31 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2ACD18FC15 for ; Thu, 16 Feb 2012 04:30:30 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1827600vcm.13 for ; Wed, 15 Feb 2012 20:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GZqnhxIAEs9xaXXTqHLoDv6OOFZVuv+rLk9FKrYN6LY=; b=q4lexb/glJh6tJ81zA0xhUZ9T04HIMShVSOjDLH8nkb5fEr2EfZiIO4/SeUjm7iNuB 4eunj+eaqrHN5c9oy3UKDWy4/24NoSo6Ep8IVF7xZUSpz3R+PT0zjwLiZ1rZVEu6KSYa vsOt8haRY8/IBoFuFWPZNSn27lU+Zzc7rhock= MIME-Version: 1.0 Received: by 10.52.96.70 with SMTP id dq6mr376269vdb.124.1329366630379; Wed, 15 Feb 2012 20:30:30 -0800 (PST) Received: by 10.220.195.66 with HTTP; Wed, 15 Feb 2012 20:30:30 -0800 (PST) In-Reply-To: References: <201111081005.43851.jhb@freebsd.org> Date: Wed, 15 Feb 2012 23:30:30 -0500 Message-ID: From: Arnaud Lacombe To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 04:30:31 -0000 Hi, Vijay Singh wrote; > In the code below: > (kgdb-amd64-6.8-48) l > 402 if (c_lock != NULL) { > 403 if (c_lock == &Giant.lock_object) { > 404 mtx_lock(&Giant); > 405 mtx_assert(&Giant, MA_OWNED); > 406 } else { > 407 class->lc_lock(c_lock, sharedlock); > 408 } > Out of curiosity, where does your code comes from ? The same snippet from the `release/8.1.0' branch does not refer to `Giant' at all, it only reads: if (c_lock != NULL) { class->lc_lock(c_lock, sharedlock); Thanks, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 04:35:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 718A11065670; Thu, 16 Feb 2012 04:35:00 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 10A0E8FC1C; Thu, 16 Feb 2012 04:34:59 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1829916vcm.13 for ; Wed, 15 Feb 2012 20:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=i9BGTRakjOUlKoqHwemleQoqsoNND5G0JvC1QgmSPnU=; b=RQfCxuecXBya8FZdxlD7RQI9O+Kdqs/w7I9BAEPZWnAvCphBrZWvtHobc8ffTTb/w8 uw5BKLfAcXtTsB1fj+fBWh6OcKdI3pIx6AMJx5HMrDpssrP9FwLWyCDIFIgB1qhRaWDB SEbum3v6qCZrZLs5y4e0GiOgBuku+q5CJ+m4w= MIME-Version: 1.0 Received: by 10.52.34.4 with SMTP id v4mr354315vdi.85.1329366899394; Wed, 15 Feb 2012 20:34:59 -0800 (PST) Received: by 10.220.179.131 with HTTP; Wed, 15 Feb 2012 20:34:59 -0800 (PST) In-Reply-To: References: <201111081005.43851.jhb@freebsd.org> Date: Wed, 15 Feb 2012 20:34:59 -0800 Message-ID: From: Vijay Singh To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 04:35:00 -0000 > Out of curiosity, where does your code comes from ? The same snippet > from the =A0`release/8.1.0' branch does not refer to `Giant' at all, it > only reads: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (c_lock !=3D NULL) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 class->lc_lock(c_lock, shared= lock); Arnaud, I added that code to track down the issue. I was originally hitting the panic much later after the callout had been executed. -vijay From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 04:41:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1534A106566C; Thu, 16 Feb 2012 04:41:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 398238FC17; Thu, 16 Feb 2012 04:41:34 +0000 (UTC) Received: by eekb47 with SMTP id b47so683033eek.13 for ; Wed, 15 Feb 2012 20:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sD15oTpfXPrn0+n9dfcqfD6Wpag4Rc7NFnqm1t9ecJU=; b=wunk20/PtEbf331PPiSWWRfS6uigPjM8BX/nFyRSzdu6jHrEw4oWH0GtfiwsIgmA7t Z5J8/G6jnTqOIj5SlK6chDvec84H2QumCoJgHNcPFsp4B9H3M+NXm3yw6Rd7haUnOMmT RUsmNCAxk91x16/v0+nO3Q1Vi5mEfCZbh5zW8= Received: by 10.14.200.196 with SMTP id z44mr591424een.116.1329367294151; Wed, 15 Feb 2012 20:41:34 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n58sm18835414een.10.2012.02.15.20.41.32 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 20:41:33 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3C88FB.6080006@FreeBSD.org> Date: Thu, 16 Feb 2012 06:41:31 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 04:41:36 -0000 On 02/15/12 21:54, Jeff Roberson wrote: > On Wed, 15 Feb 2012, Alexander Motin wrote: > >> On 02/14/12 00:38, Alexander Motin wrote: >>> I see no much point in committing them sequentially, as they are quite >>> orthogonal. I need to make one decision. I am going on small vacation >>> next week. It will give time for thoughts to settle. May be I indeed >>> just clean previous patch a bit and commit it when I get back. I've >>> spent too much time trying to make these things formal and so far >>> results are not bad, but also not so brilliant as I would like. May be >>> it is indeed time to step back and try some more simple solution. >> >> I've decided to stop those cache black magic practices and focus on >> things that really exist in this world -- SMT and CPU load. I've >> dropped most of cache related things from the patch and made the rest >> of things more strict and predictable: >> http://people.freebsd.org/~mav/sched.htt34.patch > > This looks great. I think there is value in considering the other > approach further but I would like to do this part first. It would be > nice to also add priority as a greater influence in the load balancing > as well. I have feeling that for timeshare/idle threads balance should take into account not a priority, but a nice level. Priority is very unstable thing that is recalculated each time, while nice it is what really describes how much time thread should get in perspective and those values should be shuffled equally between CPUs. But I haven't thought about specific math yet. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 08:48:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B031065670; Thu, 16 Feb 2012 08:48:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 258E58FC1A; Thu, 16 Feb 2012 08:48:42 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so2231876bkc.13 for ; Thu, 16 Feb 2012 00:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dTU3RCp4m7PVk+Ee9qG+VM5sq18Isc5Rd4n+RiasG5s=; b=hIHbZ/Rf/9BeQQeIoQAzOLjk9CIPRAfsiLzkUEwwoVOBclwtYrAz8SKr3IAEDn0Fzw AzOtnQLWLo6FBAOrt/jS+HCeAEAX0BUwaLhvBCehAqla5Rz4hTk87t0XFyEIag53BrVt 4rMo1ix+5hy+5KTKiESzRup9iR/fQV7VZB+0c= Received: by 10.204.151.196 with SMTP id d4mr733205bkw.29.1329382122124; Thu, 16 Feb 2012 00:48:42 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id x22sm11270488bkw.11.2012.02.16.00.48.40 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 00:48:41 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3CC2E7.9070100@FreeBSD.org> Date: Thu, 16 Feb 2012 10:48:39 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:48:44 -0000 On 02/15/12 21:54, Jeff Roberson wrote: > On Wed, 15 Feb 2012, Alexander Motin wrote: >> As before I've tested this on Core i7-870 with 4 physical and 8 >> logical cores and Atom D525 with 2 physical and 4 logical cores. On >> Core i7 I've got speedup up to 10-15% in super-smack MySQL and >> PostgreSQL indexed select for 2-8 threads and no penalty in other >> cases. pbzip2 shows up to 13% performance increase for 2-5 threads and >> no penalty in other cases. > > Can you also test buildworld or buildkernel with a -j value twice the > number of cores? This is an interesting case because it gets little > benefit from from affinity and really wants the best balancing possible. > It's also the first thing people will complain about if it slows. All night long buildworld run on Core i7-2600K (4/8 cores) with 8GB RAM and RAID0 of two fast SSDs found no bad surprises: old new % 1 4242.33 4239.69 -0.0622299538 2 2376.4433 2340.47 -1.5137453521 4 1581.3033 1430.1733 -9.5573063055 6 1394.8033 1348.0533 -3.3517270858 8 1365.8067 1315.87 -3.6562055231 10 1312.8533 12 1350.23 1313.2667 -2.7375558238 16 1346.2267 1306.0733 -2.9826625783 20 1313.31 Each point there averaged of 3 runs. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 10:59:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3E7C1065674; Thu, 16 Feb 2012 10:59:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0CC388FC1C; Thu, 16 Feb 2012 10:59:08 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so2359389bkc.13 for ; Thu, 16 Feb 2012 02:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ytNgf8PToXLlEti8i53vjSeY9Y3WXNnsquzdtZZqHDY=; b=h8BYY3ypt3SFBXVJXFU44NorliHIxjH3cg480vz3q6a6S/4BwxzqM35ZWcEOwLtxiX ydwQ3IO/WIKBmBukCQ595JGpdGkqWTEqwRVMncHXTbGYoh8vRIVQefWDbL9mjvEhFhdu ATD7SCSti5e0Wu9825G6fOgPM95G/c66mSeFg= Received: by 10.204.145.72 with SMTP id c8mr928860bkv.81.1329389948028; Thu, 16 Feb 2012 02:59:08 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id x20sm12071628bka.9.2012.02.16.02.59.06 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 02:59:07 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3CE179.7070605@FreeBSD.org> Date: Thu, 16 Feb 2012 12:59:05 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3CC2E7.9070100@FreeBSD.org> In-Reply-To: <4F3CC2E7.9070100@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 10:59:10 -0000 On 02/16/12 10:48, Alexander Motin wrote: > On 02/15/12 21:54, Jeff Roberson wrote: >> On Wed, 15 Feb 2012, Alexander Motin wrote: >>> As before I've tested this on Core i7-870 with 4 physical and 8 >>> logical cores and Atom D525 with 2 physical and 4 logical cores. On >>> Core i7 I've got speedup up to 10-15% in super-smack MySQL and >>> PostgreSQL indexed select for 2-8 threads and no penalty in other >>> cases. pbzip2 shows up to 13% performance increase for 2-5 threads and >>> no penalty in other cases. >> >> Can you also test buildworld or buildkernel with a -j value twice the >> number of cores? This is an interesting case because it gets little >> benefit from from affinity and really wants the best balancing possible. >> It's also the first thing people will complain about if it slows. > > All night long buildworld run on Core i7-2600K (4/8 cores) with 8GB RAM > and RAID0 of two fast SSDs found no bad surprises: > > old new % > 1 4242.33 4239.69 -0.0622299538 > 2 2376.4433 2340.47 -1.5137453521 > 4 1581.3033 1430.1733 -9.5573063055 > 6 1394.8033 1348.0533 -3.3517270858 > 8 1365.8067 1315.87 -3.6562055231 > 10 1312.8533 > 12 1350.23 1313.2667 -2.7375558238 > 16 1346.2267 1306.0733 -2.9826625783 > 20 1313.31 > > Each point there averaged of 3 runs. Ah! Just recalled, this kernel included patch from avg@ that removed extra equal topology level from the tree. That could improve balancer behavior in this case of single-socket system. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 17:47:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA78A1065670 for ; Thu, 16 Feb 2012 17:47:53 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 96C4F8FC08 for ; Thu, 16 Feb 2012 17:47:53 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id agsM1i0011ei1Bg51hae75; Thu, 16 Feb 2012 17:34:38 +0000 Received: from hans3 ([66.30.197.229]) by omta24.westchester.pa.mail.comcast.net with comcast id ahad1i00Q4xSlmi3khad1T; Thu, 16 Feb 2012 17:34:37 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ry5E4-000HRq-ED; Thu, 16 Feb 2012 12:34:36 -0500 From: Alex Goncharov To: freebsd-hackers@FreeBSD.org Message-Id: Sender: Alex Goncharov Date: Thu, 16 Feb 2012 12:34:36 -0500 Cc: Subject: 8 to 9: A longer wait early in the boot of a (damaged) Compaq Presario X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:47:54 -0000 About three years ago, my Compaq Presario F700 notebook got "damaged in BIOS": it carried Windows Vista then, and that OS could not be recovered from the system image disks I had created for a brand-new machine. The damage was somewhere around BIOS/firmware area -- the way the console looked on a bootup looked differently (simpler) now that after several reboots trying to recover Vista, it got fried. Some googling told me then that the irreversible loss of Windows was not unusual for these Compaq machines -- the damaged systems didn't give one a chance to use the recovery disks. OK, I made the system dual bootable to Debian Linux and FreeBSD 8 then; with that, it booted all right, but in both cases the 'nfe0' interface Ethernet address was being set to 0. No big deal: I used an Ethernet address from my older laptop destined to be destroyed and gave it to 'nfe0' when setting the network interface properties at the system initialization. Works great, both in Debian and FreeBSD. There was one other odd thing that I noticed then: while Debian booted without a delay, FreeBSD 8 made a long pause after passing the boot menu: it would display the '/' character and sit there for some non-trivial amount of seconds. I assumed that it was doing some BIOS querying, and with BIOS (firmware?) being damaged, it took the system some time to figure things out... perhaps it was re-querying BIOS, seeing the insane value of 0 for an interface's Ethernet address (I have many machines running FreeBSD, including multiple laptops, and this machine is unique in the long bootup pause). About a week ago, I made a jump and upgraded the system's FreeBSD from version 8 to 9. Everything is great (I am typing this message on that machine now) but the boot pause after the (looking new in 9) boot menu is *much* longer now -- it will show the '\' character and wait for, subjectively, half a minute before putting anything else on the screen. This is not of any practical importance for me, I feel very good about what I got in FreeBSD 9 but I am puzzled and earn for the knowledge. Can anybody educate me on: * What might have happened with this notebook three years ago, when some layer over BIOS "burned out"? What are these layers? Where are the interface Ethernet addresses set up? Interesting, it was only this interface that lost its factory-assigned address: ---------------------------------------- nfe0@pci0:0:10:0: class=0x020000 card=0x30ea103c chip=0x054c10derev=0xa2 hdr=0x00 vendor = 'nVidia Corporation' device = 'MCP67 Ethernet' ---------------------------------------- but not this one: ---------------------------------------- ath0@pci0:3:0:0: class=0x020000 card=0x137a103c chip=0x001c168crev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR242x / AR542x Wireless Network Adapter (PCI-Express)' ---------------------------------------- * What is the boot process doing, hanging out there after passing the boot menu stage? * Why does it hang there longer in FreeBSD 9, compared to 8? (And why doesn't it hang there at all in Debian?) * Is there any loader.conf variable or some such that would tell the system to safely skip things leading to this pause? Thanks, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 18:21:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC646106564A for ; Thu, 16 Feb 2012 18:21:56 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 78A718FC0A for ; Thu, 16 Feb 2012 18:21:56 +0000 (UTC) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id aiLD1i00616LCl05DiMwTb; Thu, 16 Feb 2012 18:21:56 +0000 Received: from hans3 ([66.30.197.229]) by omta06.westchester.pa.mail.comcast.net with comcast id aiMw1i00T4xSlmi3SiMwec; Thu, 16 Feb 2012 18:21:56 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ry5xr-000HUH-6Q for freebsd-hackers@FreeBSD.org; Thu, 16 Feb 2012 13:21:55 -0500 From: Alex Goncharov To: freebsd-hackers@FreeBSD.org In-reply-to: <4F3D460E.7090507@gmail.com> (message from Rares Aioanei on Thu, 16 Feb 2012 20:08:14 +0200) References: <4F3D460E.7090507@gmail.com> Message-Id: Sender: Alex Goncharov Date: Thu, 16 Feb 2012 13:21:55 -0500 Cc: Subject: Re: 8 to 9: A longer wait early in the boot of a (damaged) Compaq Presario X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:21:56 -0000 ,--- I/Alex (Thu, 16 Feb 2012 12:34:36 -0500) ----* | There was one other odd thing that I noticed then: while Debian booted | without a delay, FreeBSD 8 made a long pause after passing the boot | menu: it would display the '/' character and sit there for some | non-trivial amount of seconds. I assumed that it was doing some BIOS | querying, and with BIOS (firmware?) being damaged, it took the system | some time to figure things out... perhaps it was re-querying BIOS, | seeing the insane value of 0 for an interface's Ethernet address (I | have many machines running FreeBSD, including multiple laptops, and | this machine is unique in the long bootup pause). `-------------------------------------------------* ,--- Rares Aioanei (Thu, 16 Feb 2012 20:08:14 +0200) ----* | I get the same on my HP Pavilion dv9750 laptop, but with an intact BIOS, | afaict. And that happens regardless of the wi-fi card's state (eg | disabled or enabled from the hardware button). Maybe this helps. `--------------------------------------------------------* To add to the fact base: I don't have any of this with my HP Pavilion DV6-1334US: neither with FreeBSD 8 nor 9 (upgraded that laptop two days ago, too.) -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 19:04:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0953106564A for ; Thu, 16 Feb 2012 19:04:48 +0000 (UTC) (envelope-from bsdlisten@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 52F428FC12 for ; Thu, 16 Feb 2012 19:04:48 +0000 (UTC) Received: by eekb47 with SMTP id b47so1174767eek.13 for ; Thu, 16 Feb 2012 11:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vznz7RwQi3Se/N0G5T1UsM1szfcRkYEy5wa1Jl9dIX0=; b=uWCzHFlwcRfvTaqMe/eTlG+ok03sXCJHsvmGXZlAOF3ub0IgJPNa+g4xb9mLt9tD4U pJcNWNCnggb6z+XGVYubO8XVs/vix9bt8JAIVtTNmIYCB9NAjZDtaELGd64Dy0Akf8OE fNvEp3jyFk9SVhzb/fJBFa7EMx7qQYYxtzEhk= Received: by 10.112.29.6 with SMTP id f6mr1401736lbh.69.1329415703253; Thu, 16 Feb 2012 10:08:23 -0800 (PST) Received: from [192.168.0.100] ([89.47.83.116]) by mx.google.com with ESMTPS id op8sm6853352lab.15.2012.02.16.10.08.21 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 10:08:22 -0800 (PST) Message-ID: <4F3D460E.7090507@gmail.com> Date: Thu, 16 Feb 2012 20:08:14 +0200 From: Rares Aioanei User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: Alex Goncharov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: 8 to 9: A longer wait early in the boot of a (damaged) Compaq Presario X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:04:48 -0000 On 02/16/2012 07:34 PM, Alex Goncharov wrote: > About three years ago, my Compaq Presario F700 notebook got "damaged > in BIOS": it carried Windows Vista then, and that OS could not be > recovered from the system image disks I had created for a brand-new > machine. The damage was somewhere around BIOS/firmware area -- the > way the console looked on a bootup looked differently (simpler) now > that after several reboots trying to recover Vista, it got fried. > > Some googling told me then that the irreversible loss of Windows was > not unusual for these Compaq machines -- the damaged systems didn't > give one a chance to use the recovery disks. > > OK, I made the system dual bootable to Debian Linux and FreeBSD 8 > then; with that, it booted all right, but in both cases the 'nfe0' > interface Ethernet address was being set to 0. No big deal: I used an > Ethernet address from my older laptop destined to be destroyed and > gave it to 'nfe0' when setting the network interface properties at the > system initialization. Works great, both in Debian and FreeBSD. > > There was one other odd thing that I noticed then: while Debian booted > without a delay, FreeBSD 8 made a long pause after passing the boot > menu: it would display the '/' character and sit there for some > non-trivial amount of seconds. I assumed that it was doing some BIOS > querying, and with BIOS (firmware?) being damaged, it took the system > some time to figure things out... perhaps it was re-querying BIOS, > seeing the insane value of 0 for an interface's Ethernet address (I > have many machines running FreeBSD, including multiple laptops, and I get the same on my HP Pavilion dv9750 laptop, but with an intact BIOS, afaict. And that happens regardless of the wi-fi card's state (eg disabled or enabled from the hardware button). Maybe this helps. -- Rares Aioanei From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 19:04:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4522C106564A for ; Thu, 16 Feb 2012 19:04:51 +0000 (UTC) (envelope-from prvs=139337f927=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C43BA8FC16 for ; Thu, 16 Feb 2012 19:04:50 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 16 Feb 2012 18:36:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018097106.msg for ; Thu, 16 Feb 2012 18:35:59 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=139337f927=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <3C638A871829485CB0A9B3285CA23352@multiplay.co.uk> From: "Steven Hartland" To: "Alex Goncharov" , References: Date: Thu, 16 Feb 2012 18:23:15 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_06ED_01CCECD8.0CB76B60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Subject: Re: 8 to 9: A longer wait early in the boot of a (damaged) CompaqPresario X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:04:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06ED_01CCECD8.0CB76B60 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Alex Goncharov" > About a week ago, I made a jump and upgraded the system's FreeBSD from > version 8 to 9. Everything is great (I am typing this message on that > machine now) but the boot pause after the (looking new in 9) boot menu > is *much* longer now -- it will show the '\' character and wait for, > subjectively, half a minute before putting anything else on the > screen. Two things spring to mind which could help: 1. The reduce the slice sampling size in sys/boot/zfs/zfs.c which was increased recently 2. disable boot time mem tests using the attached patch Patches for both from 8.2-RELEASE attached. For #2 you also need the following in /boot/loader.conf hw.memtest.tests="0" Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_06ED_01CCECD8.0CB76B60 Content-Type: text/plain; format=flowed; name="boot-memtest-tunable.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="boot-memtest-tunable.txt" --- sys/amd64/amd64/machdep.c 2011/06/08 08:12:15 222853=0A= +++ sys/amd64/amd64/machdep.c 2011/07/30 13:33:05 224516=0A= @@ -1309,7 +1309,7 @@=0A= {=0A= int i, physmap_idx, pa_indx, da_indx;=0A= vm_paddr_t pa, physmap[PHYSMAP_SIZE];=0A= - u_long physmem_tunable;=0A= + u_long physmem_tunable, memtest, tmpul;=0A= pt_entry_t *pte;=0A= struct bios_smap *smapbase, *smap, *smapend;=0A= u_int32_t smapsize;=0A= @@ -1372,6 +1372,14 @@=0A= Maxmem =3D atop(physmem_tunable);=0A= =0A= /*=0A= + * By default keep the memtest enabled. Use a general name so that=0A= + * one could eventually do more with the code than just disable it.=0A= + */=0A= + memtest =3D 1;=0A= + if (TUNABLE_ULONG_FETCH("hw.memtest.tests", &tmpul))=0A= + memtest =3D tmpul;=0A= +=0A= + /*=0A= * Don't allow MAXMEM or hw.physmem to extend the amount of memory=0A= * in the system.=0A= */=0A= @@ -1433,6 +1441,8 @@=0A= goto do_dump_avail;=0A= =0A= page_bad =3D FALSE;=0A= + if (memtest =3D=3D 0)=0A= + goto skip_memtest;=0A= =0A= /*=0A= * map page into kernel: valid, read/write,non-cacheable=0A= @@ -1470,6 +1480,7 @@=0A= */=0A= *(int *)ptr =3D tmp;=0A= =0A= +skip_memtest:=0A= /*=0A= * Adjust array of valid/good pages.=0A= */=0A= ------=_NextPart_000_06ED_01CCECD8.0CB76B60 Content-Type: text/plain; format=flowed; name="zfs-slice-boot.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfs-slice-boot.txt" --- sys/boot/zfs/zfs.c.orig 2011-10-20 18:15:29.966685430 +0000=0A= +++ sys/boot/zfs/zfs.c 2011-10-20 18:18:22.291033636 +0000=0A= @@ -45,6 +45,12 @@=0A= =0A= #include "zfsimpl.c"=0A= =0A= +/*=0A= + * For GPT this should be 128 but leads to 50+ second delay in BTX = loader so=0A= + * we use the original 4 pre r198420 by default for the boot process=0A= + */=0A= +#define ZFS_MAX_SLICES 4=0A= +=0A= static int zfs_open(const char *path, struct open_file *f);=0A= static int zfs_write(struct open_file *f, void *buf, size_t size, = size_t *resid);=0A= static int zfs_close(struct open_file *f);=0A= @@ -415,7 +421,7 @@=0A= if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))=0A= close(fd);=0A= =0A= - for (slice =3D 1; slice <=3D 128; slice++) {=0A= + for (slice =3D 1; slice <=3D ZFS_MAX_SLICES; slice++) {=0A= sprintf(devname, "disk%dp%d:", unit, slice);=0A= fd =3D open(devname, O_RDONLY);=0A= if (fd =3D=3D -1) {=0A= ------=_NextPart_000_06ED_01CCECD8.0CB76B60-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 16 21:28:51 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C89106566C; Thu, 16 Feb 2012 21:28:51 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D67F38FC14; Thu, 16 Feb 2012 21:28:50 +0000 (UTC) Received: from nibbler-wlan.fritz.box (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1GLSmOH004101; Thu, 16 Feb 2012 21:28:49 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4F3D750F.8000100@FreeBSD.org> Date: Thu, 16 Feb 2012 22:28:47 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Alexander Motin References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> In-Reply-To: <4F3C0BB9.6050101@FreeBSD.org> X-Enigmail-Version: 1.4a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC4E5750348613DA918A41115" Cc: freebsd-hackers@FreeBSD.org, Jeff Roberson , Andriy Gapon Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:28:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC4E5750348613DA918A41115 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 15.02.12 20:47, Alexander Motin wrote: > On 02/14/12 00:38, Alexander Motin wrote: >> I see no much point in committing them sequentially, as they are quite= >> orthogonal. I need to make one decision. I am going on small vacation >> next week. It will give time for thoughts to settle. May be I indeed >> just clean previous patch a bit and commit it when I get back. I've >> spent too much time trying to make these things formal and so far >> results are not bad, but also not so brilliant as I would like. May be= >> it is indeed time to step back and try some more simple solution. >=20 > I've decided to stop those cache black magic practices and focus on=20 > things that really exist in this world -- SMT and CPU load. I've droppe= d=20 > most of cache related things from the patch and made the rest of things= =20 > more strict and predictable: > http://people.freebsd.org/~mav/sched.htt34.patch >=20 > This patch adds check to skip fast previous CPU selection if it's SMT=20 > neighbor is in use, not just if no SMT present as in previous patches. >=20 > I've took affinity/preference algorithm from the first patch and=20 > improved it. That makes pickcpu() to prefer previous core or it's=20 > neighbors in case of equal load. That is very simple to keep it, but=20 > still should give cache hits. >=20 > I've changed the general algorithm of topology tree processing. First I= =20 > am looking for idle core on the same last-level cache as before, with=20 > affinity to previous core or it's neighbors on higher level caches.=20 > Original code could put additional thread on already busy core, while=20 > next socket is completely idle. Now if there is no idle core on this=20 > cache, then all other CPUs are checked. >=20 > CPU groups comparison now done in two steps: first, same as before,=20 > compared summary load of all cores; but now, if it is equal, I am=20 > comparing load of the less/most loaded cores. That should allow to=20 > differentiate whether load 2 really means 1+1 or 2+0. In that case grou= p=20 > with 2+0 will be taken as more loaded than one with 1+1, making group=20 > choice more grounded and predictable. >=20 > I've added randomization in case if all above factors are equal. >=20 > As before I've tested this on Core i7-870 with 4 physical and 8 logical= =20 > cores and Atom D525 with 2 physical and 4 logical cores. On Core i7 I'v= e=20 > got speedup up to 10-15% in super-smack MySQL and PostgreSQL indexed=20 > select for 2-8 threads and no penalty in other cases. pbzip2 shows up t= o=20 > 13% performance increase for 2-5 threads and no penalty in other cases.= >=20 > Tests on Atom show mostly about the same performance as before in=20 > database benchmarks: faster for 1 thread, slower for 2-3 and about the = > same for other cases. Single stream network performance improved same a= s=20 > for the first patch. That CPU is quite difficult to handle as with mix = > of effective SMT and lack of L3 cache different scheduling approaches=20 > give different results in different situations. >=20 > Specific performance numbers can be found here: > http://people.freebsd.org/~mav/bench.ods > Every point there includes at least 5 samples and except pbzip2 test=20 > that is quite unstable with previous sources all are statistically vali= d. >=20 > Florian is now running alternative set of benchmarks on dual-socket=20 > hardware without SMT. >=20 I have updated my PostgreSQL [1] and pbzip2 [2] benchmarks. You should be looking for "ULE+mav-htt33". On a system without HTT this patch is at least as good as stock ULE and in some cases it's a nice improvement. Florian [1] https://docs.google.com/spreadsheet/ccc?key=3D0Ai0N1xDe3uNAdDRxcVFiYjNMSn= JWOTZhUWVWWlBlemc&hl=3Den_US&pli=3D1#gid=3D4 [2]https://docs.google.com/spreadsheet/ccc?key=3D0Ai0N1xDe3uNAdDRxcVFiYjN= MSnJWOTZhUWVWWlBlemc&hl=3Den_US&pli=3D1#gid=3D2 --------------enigC4E5750348613DA918A41115 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk89dRAACgkQapo8P8lCvwmbFACeMCqzyrBB4Sd49R4DvrHJI2bc QosAn360DLeyOI7bb2MVpm/XBNvBJ5eg =ABoK -----END PGP SIGNATURE----- --------------enigC4E5750348613DA918A41115-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 00:11:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA32106566B for ; Fri, 17 Feb 2012 00:11:56 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8B38FC08 for ; Fri, 17 Feb 2012 00:11:56 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id anfF1i0021ei1Bg59oBwSA; Fri, 17 Feb 2012 00:11:56 +0000 Received: from hans3 ([66.30.197.229]) by omta24.westchester.pa.mail.comcast.net with comcast id aoBw1i0054xSlmi3koBwzj; Fri, 17 Feb 2012 00:11:56 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyBQZ-000Hmj-2E; Thu, 16 Feb 2012 19:11:55 -0500 From: Alex Goncharov To: "Steven Hartland" In-reply-to: <3C638A871829485CB0A9B3285CA23352@multiplay.co.uk> (killing@multiplay.co.uk) References: <3C638A871829485CB0A9B3285CA23352@multiplay.co.uk> Message-Id: Sender: Alex Goncharov Date: Thu, 16 Feb 2012 19:11:55 -0500 Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: A longer wait early in the boot of a (damaged) CompaqPresario X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:11:57 -0000 ,--- You/Steven (Thu, 16 Feb 2012 18:23:15 -0000) ----* | Two things spring to mind which could help: | 1. The reduce the slice sampling size in sys/boot/zfs/zfs.c which was | increased recently Your mentioning of ZFS made me realize that I was building RELENG_{8,9} with /etc/src.conf not excluding it; I'll try to rebuild 9 with "WITHOUT_ZFS = 1". | 2. disable boot time mem tests using the attached patch | | Patches for both from 8.2-RELEASE attached. For #2 you also need the | following in /boot/loader.conf | hw.memtest.tests="0" I'll try this later, hopefully within a week, but I doubt the likelihood of good effects from either: after all, the same builds used on my HP Pavilion (4G of memory) have always led to non-pausing bootups, as opposed to the pausing ones in my (damaged) Compaq Presario (2G of memory.) Thanks! -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 01:52:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049B0106564A for ; Fri, 17 Feb 2012 01:52:02 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id 95B508FC0A for ; Fri, 17 Feb 2012 01:52:01 +0000 (UTC) X-AuditID: 1209190d-b7fbf6d0000008ba-9d-4f3db2c0d7bc Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D6.60.02234.0C2BD3F4; Thu, 16 Feb 2012 20:52:00 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q1H1q0Y6000949; Thu, 16 Feb 2012 20:52:00 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q1H1pxNg018321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Feb 2012 20:52:00 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id q1H1pwQG022799; Thu, 16 Feb 2012 20:51:58 -0500 (EST) Date: Thu, 16 Feb 2012 20:51:58 -0500 (EST) From: Benjamin Kaduk To: Ansar Mohammed In-Reply-To: Message-ID: References: <487167524.1045003.1328751695510.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nontgk62/wcYXOhYrz61nsti++R+j A5PHjE/zWTx2zrrLHsAUxWWTkpqTWZZapG+XwJWx+M8u5oKD7BWNt/6wNzB+Y+1i5OSQEDCR 6Nt3gh3CFpO4cG89WxcjF4eQwD5Gid0PO1lAEkICGxglTjyMhkgcYJJYfOYTE4TTwCjRffYE WBWLgLbE/Gs3wGw2ARWJmW82soHYIgKqEsvPnweLMwvIS1zYfIgRxBYWUJS4euc72GpOgUCJ 0x9+AtVzcPAKOEp8umUCMb+fSeLjxjtg9aICOhKr908Bm8MrIChxcuYTqJmWEuf+XGebwCg4 C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGEGhyinJu4Px3UGl Q4wCHIxKPLxJhrb+QqyJZcWVuYcYJTmYlER5fYGBLsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE N18GKMebklhZlVqUD5OS5mBREudV1XrnJySQnliSmp2aWpBaBJOV4eBQkuBtBRkqWJSanlqR lplTgpBm4uAEGc4DNLwEpIa3uCAxtzgzHSJ/ilGX4+6RJxcYhVjy8vNSpcR5c0GKBECKMkrz 4ObAUswrRnGgt4R5c0CqeIDpCW7SK6AlTEBLzF9YgSwpSURISTUwtu84Wrn+hfTbzapqwpbO 3DlyL0TC/OPPaNrekTM5/a0m9KxOFTM3X7+HVNTlFZ9Pzkhf8EkqMW4Py9/JOc6L6lJbGxpK KtWfh6x98WTP9kcnGB54u7R23tnJ6lTx8oA6xwr7qGUt8QXzJu5+/TWhJ/RN6l6eH5waq3xm /5q9+9frEzu2WJ/1VGIpzkg01GIuKk4EALb14t0MAwAA Cc: freebsd-hackers@freebsd.org Subject: Re: Kerberos and FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 01:52:02 -0000 On Wed, 15 Feb 2012, Ansar Mohammed wrote: > Going back on this topic, it seems that there are alot of things that > are being shipped with FreeBSD that I am not sure we need in the base > distribution. > > Does anyone use portalfs? Maybe not ... per http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS it is scheduled for removal from the tree in September if no one gives it some love. For things like that, which are perhaps useful to someone, somewhere, I see no harm in keeping them around if there is minimal effort in doing so. But, when there comes a point where substantial effort is required for upkeep, if there is not a visible use, removing them (with advance warning on the order of a year) seems like the right thing to do. We don't really have the manpower to make gratuitous changes to what's in the tree just for the sake of making changes, and removing anything has a chance of sparking a big flamewar. -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 05:12:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05EE7106564A for ; Fri, 17 Feb 2012 05:12:51 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BAB6C8FC08 for ; Fri, 17 Feb 2012 05:12:50 +0000 (UTC) Received: by iaeo4 with SMTP id o4so5126006iae.13 for ; Thu, 16 Feb 2012 21:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=Lo9zZrOTkPxG+R/PlGK4o7NvIx1ZKEbNVVYD9/d80Cw=; b=moM1qFTNRMeeeN3pKfkwixFGG0DBUTaxQkiMp0xM1FgMRdekW6Std+90gEa//BXz29 WMUJtG33GVLLZO65WifDs6D0raQfCel94hZq3ny8eXKs5B8I5m8IPL0TAFVr/yzPwHYo MtScbqYlbgLVexO2bI8zofd/aFCk2yQX8T4eM= Received: by 10.50.85.231 with SMTP id k7mr21551389igz.25.1329455570192; Thu, 16 Feb 2012 21:12:50 -0800 (PST) Received: from DataIX.net (adsl-99-181-134-79.dsl.klmzmi.sbcglobal.net. [99.181.134.79]) by mx.google.com with ESMTPS id vr4sm4656719igb.1.2012.02.16.21.12.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Feb 2012 21:12:48 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1H5Ci8U004975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 00:12:45 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1H5CilH003093; Fri, 17 Feb 2012 00:12:44 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Fri, 17 Feb 2012 00:12:44 -0500 From: Jason Hellenthal To: Ansar Mohammed Message-ID: <20120217051244.GA21997@DataIX.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: nologin size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 05:12:51 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =46rom the Makefile... # It is important that nologin be statically linked for security # reasons. A dynamic non-setuid binary can be linked against a trojan # libc by setting LD_LIBRARY_PATH appropriately. Both sshd(8) and # login(1) make it possible to log in with an unsanitized environment, # rendering a dynamic nologin binary virtually useless. NO_SHARED=3D YES On Wed, Feb 15, 2012 at 02:28:54PM -0500, Ansar Mohammed wrote: > Hello all, > I am trying to build a minimal size FreeBSD 9 installation and I > noticed that the size of nologin is almost 200k. > I built FreeBSD from source so I checked the distribution, and it's also = 200k. > So I went back to the source and just compiled nologin.c and it came up t= o 5k. >=20 > Can anyone explain why this executable is so large? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --=20 ;s =3D; --FCuugMFkClbJLl1L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPPeHLAAoJEJBXh4mJ2FR+hggIAJFzQolWpvbw2AmcPuQscHXz l0U3cU9v1k3y4EkaED8YgvMI11WISOR/VgjF8OzRbtIi1USgOnWuqMj+G85O8n6+ 4pBtA1zmVGYqdbuTEYLNEhUWj3XHAtkFq5UrHJ+DPx1FI/oikVTni2CXnIAxg5Tf QVySixyUIFH5k4bYjiv6p00o1TOskC5yJ1uZs9usAYHgRT9CvkfK/vnC8ldjjfc7 b1koBNObS/Y/d0WVkrJH65GqWcc6alHYmHz6uWDkPAXjLuRmv4lUr6Pgh87gmYrm 00feY9CuT97mNp3s2q3vMJPt5rmDPTUmRfqbQO8q8OuDFa/dJjJJl9P/BIPYB/4= =Mp/b -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 07:43:58 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072CD106564A for ; Fri, 17 Feb 2012 07:43:58 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 91A3A8FC15 for ; Fri, 17 Feb 2012 07:43:57 +0000 (UTC) Received: by werm13 with SMTP id m13so2634459wer.13 for ; Thu, 16 Feb 2012 23:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=rAK8wXzlwFHP9k3CQPJiwY/2vbZJMpI+zyPdqfldv4g=; b=Oc99pv76CAkHMJ2u5GQ1HYncOlo0wzSZ6VJrUN0WfqeLTOo/s9nrP85v6x2bZox5B7 mU0OPd5WlJ8d2v6P7LmIiNUv7wERGwVAVEPAmyB+Uidwi21f5UTekXB8s52A7bDKbBLM QeTSNF1wY9NJA1ip/Hp/HMjr6rQFfnMvYueH4= Received: by 10.180.101.228 with SMTP id fj4mr1703325wib.4.1329464636146; Thu, 16 Feb 2012 23:43:56 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id dw7sm5690951wib.4.2012.02.16.23.43.27 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 23:43:54 -0800 (PST) Message-ID: <20120217.074355.853.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@FreeBSD.org Date: Fri, 17 Feb 2012 08:43:55 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: BUG: 9.0 stage 2 boot (/boot/boot) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 07:43:58 -0000 Anyway, after upgrading to 9.0, my USB stick, when created, started to hang = at stage 2 boot.=0D=0AI have a custom setup, where BSD label 'a', has a = content of /boot/*=0D=0ASo when 'a' is being hit by stage 2 boot, there = is boot.config waiting for it.=0D=0AAfter it reads it and displays it's = content, it echos 'No' and hangs.=0D=0A=0D=0AI stare at it and can't = believe as boot.config's information is correct!=0D=0AI hit '?' and it = list all files in 'a'.=0D=0AThen I simply RE-type what is displayed on = screen (content of boot.config -> path to loader)=0D=0AAnd loader kicks = in!=0D=0A=0D=0AI do this a few times more and EACH time I have to RE-type = correct info!=0D=0ATested on other machine, same = thing.=0D=0A=0D=0AHowever, this same custom layout works for HDD's, but = NOT for USB stick.=0D=0A=0D=0AI've extracted binary installs of 8.2 and = 9.0 R:=0D=0AMD5 (8_boot) =3D adb1e84e96bd434e51cafaaa0ef22584=0D=0AMD5 = (9_boot) =3D 40f3f6403ebd5e131259d1336b4b50ad=0D=0A=0D=0AThen:=0D=0A# = gpart bootcode -b 8_boot da0s2=0D=0AAnd sudenly that USB stick boots, = without ANY other change!=0D=0AJust an "old" stage 2 boot code, from R8 = was enough.=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 10:48:41 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADA8D1065670 for ; Fri, 17 Feb 2012 10:48:41 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 0477B8FC0C for ; Fri, 17 Feb 2012 10:48:40 +0000 (UTC) Received: (qmail 80844 invoked by uid 1004); 17 Feb 2012 10:49:04 -0000 Message-ID: <4F3E3074.20308@uffe.org> Date: Fri, 17 Feb 2012 11:48:20 +0100 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <4F3D460E.7090507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Goncharov Subject: Re: 8 to 9: A longer wait early in the boot of a (damaged) Compaq Presario X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 10:48:41 -0000 On 2012-02-16 19:21, Alex Goncharov wrote: > ,--- I/Alex (Thu, 16 Feb 2012 12:34:36 -0500) ----* > | There was one other odd thing that I noticed then: while Debian booted > | without a delay, FreeBSD 8 made a long pause after passing the boot > | menu: it would display the '/' character and sit there for some > | non-trivial amount of seconds. I assumed that it was doing some BIOS > | querying, and with BIOS (firmware?) being damaged, it took the system > | some time to figure things out... perhaps it was re-querying BIOS, > | seeing the insane value of 0 for an interface's Ethernet address (I > | have many machines running FreeBSD, including multiple laptops, and > | this machine is unique in the long bootup pause). > `-------------------------------------------------* > ,--- Rares Aioanei (Thu, 16 Feb 2012 20:08:14 +0200) ----* > | I get the same on my HP Pavilion dv9750 laptop, but with an intact BIOS, > | afaict. And that happens regardless of the wi-fi card's state (eg > | disabled or enabled from the hardware button). Maybe this helps. > `--------------------------------------------------------* > > To add to the fact base: I don't have any of this with my HP Pavilion > DV6-1334US: neither with FreeBSD 8 nor 9 (upgraded that laptop two > days ago, too.) > FreeBSD 8.x has a memory test that takes place quite early during kernel startup - I have seen a system with 128Gb ram hang for 1-2 minuttes on this account - quite annoying delay if you ask me. There were discussions about removing this memtest feature in FreeBSD 9 but I do not know if it made it into the tree in time... but you'll need to have lots of memory for this to kickin - not very likely with your laptop. Another similar boot delay/hang seen with FreeBSD 8.x with certain SATA controllers. I have a FreeBSD 8.x system that hangs exactly 75 seconds (timeout?) during (every) kernel startup when running SATA in AHCI mode (setup within the BIOS) - if switched back to SATA IDE (compatible) mode the system kernel starts instantly with out the 75 sec (timeout) hang. This problem seems resolved by the SATA/AHCI driver overhaul that FreeBSD 9 got. Both problems are visually identical (as far as I remember) - an unexplainable delay during kernel startup - it sleeps/hangs before anything is printed on screen... HTH /Uffe From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 15:05:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F71106566C for ; Fri, 17 Feb 2012 15:05:43 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 7297B8FC0C for ; Fri, 17 Feb 2012 15:05:43 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id b2ag1i00B27AodY5735jiw; Fri, 17 Feb 2012 15:05:43 +0000 Received: from hans3 ([66.30.197.229]) by omta19.westchester.pa.mail.comcast.net with comcast id b35j1i00k4xSlmi3f35jU1; Fri, 17 Feb 2012 15:05:43 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyPNW-000If4-5Y for freebsd-hackers@FreeBSD.org; Fri, 17 Feb 2012 10:05:42 -0500 From: Alex Goncharov To: freebsd-hackers@FreeBSD.org Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 10:05:42 -0500 Cc: Subject: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:05:43 -0000 Sticking with the same list as in my first message re the "8 to 9" surprises: | From: Alex Goncharov | To: freebsd-hackers@FreeBSD.org | Date: Thu, 16 Feb 2012 12:34:36 -0500 | Subject: 8 to 9: A longer wait early in the boot... | | About a week ago, I made a jump and upgraded the system's FreeBSD from | version 8 to 9. Trying to figure our audio things, I was shocked to discover that on 9 I couldn't 'kldload snd_hda.ko'; it looks like the HDA support is in the kernel itself now. Compare the two runs, on my 8 and 9 machines, with this script: -- >> ---------------------------------------------------------- #!/bin/sh set -x : ======================================== uname -sr : ======================================== grep hda /boot/loader.conf : ======================================== dmesg | grep -E 'hda|pcm' : ======================================== cat /dev/sndstat : ======================================== for f in /boot/kernel/kernel /boot/kernel/snd_hda.ko; do echo ==== $f; nm $f | grep -c hda; done : ======================================== id : ======================================== kldstat | grep -E 'sound|snd' : ======================================== kldunload snd_hda.ko : ======================================== kldstat | grep hda : ======================================== kldload snd_hda.ko : ======================================== kldstat | grep hda : ======================================== -- << ---------------------------------------------------------- On 8: -- >> ---------------------------------------------------------- * : ======================================== * uname -sr FreeBSD 8.2-STABLE * : ======================================== * grep hda /boot/loader.conf snd_hda_load="YES" * : ======================================== * dmesg * grep -E 'hda|pcm' hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm0: detached pcm1: detached pcm2: detached hdac0: detached hdac0: mem 0xfea78000-0xfea7bfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 * : ======================================== * cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: (play/rec) default pcm1: (play/rec) pcm2: (play) * : ======================================== * echo ==== /boot/kernel/kernel ==== /boot/kernel/kernel * nm /boot/kernel/kernel * grep -c hda 0 * echo ==== /boot/kernel/snd_hda.ko ==== /boot/kernel/snd_hda.ko * nm /boot/kernel/snd_hda.ko * grep -c hda 114 * : ======================================== * id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) * : ======================================== * kldstat * grep -E 'sound|snd' 3 2 0xffffffff80f09000 75878 sound.ko 11 1 0xffffffff81039000 14580 snd_hda.ko * : ======================================== * kldunload snd_hda.ko * : ======================================== * grep hda * kldstat * : ======================================== * kldload snd_hda.ko * : ======================================== * grep hda * kldstat 11 1 0xffffffff81039000 14580 snd_hda.ko * : ======================================== -- << ---------------------------------------------------------- <== All is the way I am used to: for my audio card, the support is in snd_hda.ko, which I load and unload as I will. The kernel does not contain snd_hda symbols. On 9: -- >> ---------------------------------------------------------- * : ======================================== * uname -sr FreeBSD 9.0-STABLE * : ======================================== * grep hda /boot/loader.conf snd_hda_load="YES" * : ======================================== * dmesg * grep -E 'hda|pcm' hdac0: mem 0xfe028000-0xfe02bfff irq 23 at device 5.0 on pci0 hdac0: HDA Codec #0: Realtek ALC660 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 interface snd_hda.1 already present in the KLD 'kernel'! interface snd_hda.1 already present in the KLD 'kernel'! * : ======================================== * cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: (play/rec) default pcm1: (play) * : ======================================== * echo ==== /boot/kernel/kernel ==== /boot/kernel/kernel * nm /boot/kernel/kernel * grep -c hda 114 * echo ==== /boot/kernel/snd_hda.ko ==== /boot/kernel/snd_hda.ko * nm /boot/kernel/snd_hda.ko * grep -c hda 114 * : ======================================== * id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) * : ======================================== * kldstat * grep -E 'sound|snd' * : ======================================== * kldunload snd_hda.ko kldunload: can't find file snd_hda.ko * : ======================================== * kldstat * grep hda * : ======================================== * kldload snd_hda.ko kldload: can't load snd_hda.ko: Exec format error * : ======================================== * kldstat * grep hda * : ======================================== -- << ---------------------------------------------------------- <== This is shocking to me: I have the /boot/kernel/snd_hda.ko but I can't load and unload it -- apparently the sound support is in the kernel now. Sorry if this is a trivial question, but did the kernel modularization mechanics and/or configuration change between 8 and 9? (I don't easily see anything applicable in /usr/src/UPDATING). Thanks. -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 15:14:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE91510656ED for ; Fri, 17 Feb 2012 15:14:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 309728FC08 for ; Fri, 17 Feb 2012 15:14:28 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.208.111] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 242348885; Fri, 17 Feb 2012 16:14:26 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, Alex Goncharov Date: Fri, 17 Feb 2012 16:12:36 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201202171612.36971.hselasky@c2i.net> Cc: Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:14:30 -0000 On Friday 17 February 2012 16:05:42 Alex Goncharov wrote: > <== This is shocking to me: I have the /boot/kernel/snd_hda.ko but I > can't load and unload it -- apparently the sound support is in the > kernel now. Maybe there is a missing depencency towards sound.ko. Try loading that first. --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 15:54:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D324410656FE for ; Fri, 17 Feb 2012 15:54:50 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id A37E98FC16 for ; Fri, 17 Feb 2012 15:54:50 +0000 (UTC) Received: by daec6 with SMTP id c6so3833768dae.13 for ; Fri, 17 Feb 2012 07:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=LESmGruMk4XqMogeQXEt5Q3uRcFhxrUwnIULq7HUTz8=; b=PbL/AgfbJ+2UI9qpYpHG7m7FbI5uEkUMaN1UEEi4IRA6z/XGdkYnrtkVdHZMjsMyHt 0gVqdb9EEYKFPDCC+As5/AJ0c+0j590SeCL/BRX5QRVmLbU41WledEhen/84w7LBCAuJ naoBifizhHFVJPCkWODJvejgA2F1wHIcor3rU= Received: by 10.68.72.138 with SMTP id d10mr25790734pbv.15.1329492725385; Fri, 17 Feb 2012 07:32:05 -0800 (PST) Received: from bakeneko.local ([74.195.19.178]) by mx.google.com with ESMTPS id q3sm5423976pbe.71.2012.02.17.07.32.03 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 07:32:04 -0800 (PST) Message-ID: <4F3E72B7.2050005@gmail.com> Date: Fri, 17 Feb 2012 07:31:03 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <201202171612.36971.hselasky@c2i.net> In-Reply-To: <201202171612.36971.hselasky@c2i.net> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alex Goncharov Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:54:50 -0000 On 02/17/12 07:12, Hans Petter Selasky wrote: > On Friday 17 February 2012 16:05:42 Alex Goncharov wrote: >> <=3D=3D This is shocking to me: I have the /boot/kernel/snd_hda.ko but= I >> can't load and unload it -- apparently the sound support is in the >> kernel now. > Maybe there is a missing depencency towards sound.ko. Try loading that = first. > > --HPS > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" It's in the kernel in later versions of 9-CURRENT and in 9-RELEASE on. You can't kldload or unload it because it's not a module, but part of the kernel. That doesn't preclude the presence of the file, I think. 'kldstat -v | less' should show you what's "in there". Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 16:04:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AED7C1065670 for ; Fri, 17 Feb 2012 16:04:04 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5789C8FC1A for ; Fri, 17 Feb 2012 16:04:04 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id b3f71i0081c6gX858444Hf; Fri, 17 Feb 2012 16:04:04 +0000 Received: from hans3 ([66.30.197.229]) by omta23.westchester.pa.mail.comcast.net with comcast id b4441i00Y4xSlmi3j444MT; Fri, 17 Feb 2012 16:04:04 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyQHy-000IjV-UR; Fri, 17 Feb 2012 11:04:02 -0500 From: Alex Goncharov To: matt In-reply-to: <4F3E72B7.2050005@gmail.com> (message from matt on Fri, 17 Feb 2012 07:31:03 -0800) References: <201202171612.36971.hselasky@c2i.net> <4F3E72B7.2050005@gmail.com> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 11:04:02 -0500 Cc: freebsd-hackers@freebsd.org, hselasky@c2i.net Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:04:04 -0000 ,--- You/matt (Fri, 17 Feb 2012 07:31:03 -0800) ----* | It's in the kernel in later versions of 9-CURRENT and in 9-RELEASE on. | | You can't kldload or unload it because it's not a module, but part of | the kernel. | That doesn't preclude the presence of the file, I think. | | 'kldstat -v | less' should show you what's "in there". Thanks, indeed: ---------------------------------------- uname -sr; echo ==; kldstat | grep hda; echo ==; kldstat -v | grep hda => FreeBSD 8.2-STABLE == 11 1 0xffffffff81039000 14580 snd_hda.ko == 11 1 0xffffffff81039000 14580 snd_hda.ko (/boot/kernel/snd_hda.ko) 456 hdac/snd_hda_pcm 457 pci/snd_hda ---------------------------------------- uname -sr; echo ==; kldstat | grep hda; echo ==; kldstat -v | grep hda => FreeBSD 9.0-STABLE == == 253 pci/snd_hda 252 hdac/snd_hda_pcm ---------------------------------------- But am I not screwed up then? -> I need to adjust the sound card pin assignments so that the sound can be directed to the headphones when they are plugged in. With FreeBSD 8, on several machines, I had gone through somewhat painful but ultimately meaningful and manageable routine of building the device.hints file. Essentially (consider the following an non-ordered set): kldunload snd_hda.ko kenv | grep hdac sysctl hw.snd.verbose sysctl hw.snd.verbose=4 kldload snd_hda.ko cat /dev/sndstat dmesg | grep ^hdac0 kenv hint.hdac.0.cad0.nid15.config="as=1 seq=15 device=Headphones" kldload snd_hda.ko I don't believe I can do it now that the snd_hda module cannot be reloaded in a modified kernel environment. So, how do I go about finding and modifying the sound card pin assignments in FreeBSD 9? (If I can't do it without temporarily installing FreeBSD 8, it would be a huge disappointment. :) Thanks, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 16:08:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4414A1065670 for ; Fri, 17 Feb 2012 16:08:20 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F0C808FC12 for ; Fri, 17 Feb 2012 16:08:18 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so3417628vbb.13 for ; Fri, 17 Feb 2012 08:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XxbmxHcpIY3eYjwCklu3Jd8w0CZDUVF8MJmNBrZaxOw=; b=Q/uUuWFjI7x5E71Jr2OBKY8fElH6v4qbdXFuy1lypdCt6+qX3HgRr/qVbUAuod763F dLxwrzAYhsQknSYHK51wkAi37+29/w/PkVgIHMu6xIxAChzpH1MgZ5KSSXx1fHZHtEBj Jo+HXRbVyzVq9D7nKRnd+OvoqmFZ38On6aRnQ= MIME-Version: 1.0 Received: by 10.220.210.134 with SMTP id gk6mr4016595vcb.32.1329494898567; Fri, 17 Feb 2012 08:08:18 -0800 (PST) Received: by 10.220.192.135 with HTTP; Fri, 17 Feb 2012 08:08:18 -0800 (PST) In-Reply-To: References: <201202171612.36971.hselasky@c2i.net> <4F3E72B7.2050005@gmail.com> Date: Fri, 17 Feb 2012 08:08:18 -0800 Message-ID: From: Freddie Cash To: Alex Goncharov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: matt , freebsd-hackers@freebsd.org, hselasky@c2i.net Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:08:20 -0000 On Fri, Feb 17, 2012 at 8:04 AM, Alex Goncharov wrote: > ,--- You/matt (Fri, 17 Feb 2012 07:31:03 -0800) ----* > | It's in the kernel in later versions of 9-CURRENT and in 9-RELEASE on. > | > | You can't kldload or unload it because it's not a module, but part of > | the kernel. > | That doesn't preclude the presence of the file, I think. > | > | 'kldstat -v | less' should show you what's "in there". > > Thanks, indeed: > > ---------------------------------------- > uname -sr; echo =3D=3D; kldstat | grep hda; echo =3D=3D; kldstat -v | gre= p hda > =3D> > FreeBSD 8.2-STABLE > =3D=3D > 11 =C2=A0 =C2=A01 0xffffffff81039000 14580 =C2=A0 =C2=A0snd_hda.ko > =3D=3D > 11 =C2=A0 =C2=A01 0xffffffff81039000 14580 =C2=A0 =C2=A0snd_hda.ko (/boot= /kernel/snd_hda.ko) > =C2=A0 =C2=A0 =C2=A0 =C2=A0456 hdac/snd_hda_pcm > =C2=A0 =C2=A0 =C2=A0 =C2=A0457 pci/snd_hda > ---------------------------------------- > > uname -sr; echo =3D=3D; kldstat | grep hda; echo =3D=3D; kldstat -v | gre= p hda > =3D> > FreeBSD 9.0-STABLE > =3D=3D > =3D=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0253 pci/snd_hda > =C2=A0 =C2=A0 =C2=A0 =C2=A0252 hdac/snd_hda_pcm > ---------------------------------------- > > But am I not screwed up then? -> > > I need to adjust the sound card pin assignments so that the sound can > be directed to the headphones when they are plugged in. > > With FreeBSD 8, on several machines, I had gone through somewhat > painful but ultimately meaningful and manageable routine of building > the device.hints file. > > Essentially (consider the following an non-ordered set): > > =C2=A0 =C2=A0kldunload snd_hda.ko > =C2=A0 =C2=A0kenv | grep hdac > =C2=A0 =C2=A0sysctl hw.snd.verbose > =C2=A0 =C2=A0sysctl hw.snd.verbose=3D4 > =C2=A0 =C2=A0kldload snd_hda.ko > =C2=A0 =C2=A0cat /dev/sndstat > =C2=A0 =C2=A0dmesg | grep ^hdac0 > =C2=A0 =C2=A0kenv hint.hdac.0.cad0.nid15.config=3D"as=3D1 seq=3D15 device= =3DHeadphones" > =C2=A0 =C2=A0kldload snd_hda.ko > > I don't believe I can do it now that the snd_hda module cannot be > reloaded in a modified kernel environment. > > So, how do I go about finding and modifying the sound card pin > assignments in FreeBSD 9? =C2=A0(If I can't do it without temporarily > installing FreeBSD 8, it would be a huge disappointment. :) Stick the hint into /boot/loader.conf and reboot. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 16:20:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DAC7106568B for ; Fri, 17 Feb 2012 16:20:19 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id E9A6D8FC1E for ; Fri, 17 Feb 2012 16:20:18 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta10.westchester.pa.mail.comcast.net with comcast id b4Ha1i0040Fqzac5A4LKv1; Fri, 17 Feb 2012 16:20:19 +0000 Received: from hans3 ([66.30.197.229]) by omta08.westchester.pa.mail.comcast.net with comcast id b4LJ1i00b4xSlmi3U4LKxo; Fri, 17 Feb 2012 16:20:19 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyQXh-000Il2-J6; Fri, 17 Feb 2012 11:20:17 -0500 From: Alex Goncharov To: Freddie Cash In-reply-to: (message from Freddie Cash on Fri, 17 Feb 2012 08:08:18 -0800) References: <201202171612.36971.hselasky@c2i.net> <4F3E72B7.2050005@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 11:20:17 -0500 Cc: sendtomatt@gmail.com, freebsd-hackers@freebsd.org, hselasky@c2i.net Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:20:19 -0000 ,--- You/Freddie (Fri, 17 Feb 2012 08:08:18 -0800) ----* | > So, how do I go about finding and modifying the sound card pin | > assignments in FreeBSD 9?  (If I can't do it without temporarily | > installing FreeBSD 8, it would be a huge disappointment. :) | | Stick the hint into /boot/loader.conf and reboot. How do I find the correct hint if I can't reload the sound module in the new kernel environment and explore 'dmesg', '/dev/sndstat' and the physical headphones with the new hint without a reboot? Stick something in a file (/boot/device.hints or /boot/loader.conf), reboot and see if it works... if it doesn't put a different combination of 'cad', 'nid' and 'seq' and reboot?... And again and again, till it works?.. (I would call this being grossly screwed up if I base my feelings on the FreeBSD 8 experience. :) -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 16:29:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D703E106566C; Fri, 17 Feb 2012 16:29:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id D40DC8FC13; Fri, 17 Feb 2012 16:29:50 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2567374wib.13 for ; Fri, 17 Feb 2012 08:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KXP8UYjbyB7nX9YzAUF/Mjb573NLU1We0x8InHGqndw=; b=MqkjOKBp7OtB8EhNYAS/sn7Re/ZQhEEzDs2wiuiN5sDyVuYCHPZhGu/8vD1ljUgRnP 3lcuVbDPVXFTRIL4M92Uj3wwbdfWTN9ZYF0cbG6MOVzRleJRON9kpa9uoxDms/DjRhc8 S9VZU01BM6Jm2YLfOiHcMixSrfbJZuZu/dsgc= Received: by 10.180.85.105 with SMTP id g9mr4888423wiz.12.1329496189748; Fri, 17 Feb 2012 08:29:49 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id da8sm8698841wib.6.2012.02.17.08.29.47 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 08:29:48 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3E807A.60103@FreeBSD.org> Date: Fri, 17 Feb 2012 18:29:46 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Roberson References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Florian Smeets , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:29:51 -0000 On 02/15/12 21:54, Jeff Roberson wrote: > On Wed, 15 Feb 2012, Alexander Motin wrote: >> I've decided to stop those cache black magic practices and focus on >> things that really exist in this world -- SMT and CPU load. I've >> dropped most of cache related things from the patch and made the rest >> of things more strict and predictable: >> http://people.freebsd.org/~mav/sched.htt34.patch > > This looks great. I think there is value in considering the other > approach further but I would like to do this part first. It would be > nice to also add priority as a greater influence in the load balancing > as well. I haven't got good idea yet about balancing priorities, but I've rewritten balancer itself. As soon as sched_lowest() / sched_highest() are more intelligent now, they allowed to remove topology traversing from the balancer itself. That should fix double-swapping problem, allow to keep some affinity while moving threads and make balancing more fair. I did number of tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 and 16 threads everything is stationary as it should. With 9 threads I see regular and random load move between all 8 CPUs. Measurements on 5 minutes run show deviation of only about 5 seconds. It is the same deviation as I see caused by only scheduling of 16 threads on 8 cores without any balancing needed at all. So I believe this code works as it should. Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch I plan this to be a final patch of this series (more to come :)) and if there will be no problems or objections, I am going to commit it (except some debugging KTRs) in about ten days. So now it's a good time for reviews and testing. :) -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 16:36:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FF78106566B for ; Fri, 17 Feb 2012 16:36:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id B25ED8FC12 for ; Fri, 17 Feb 2012 16:36:56 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2573550wib.13 for ; Fri, 17 Feb 2012 08:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KsQU0zRr0ZXUgAh6vc7o0VAK/6+Mg1v4z27esxOwhko=; b=H42rLJNu5bYM7W01lZkoIHz+iUuUT8o4Tx99xNaGYSIb+HraDz/rYS3kTjwhRBdVdJ rHNXR76wimbOySyYdD6E/yhzu+0iLiFPQ/ZiHCoWduE5deMRcyjPvRr1wv5GcKQWjyhF Wp4MdGLEl+eClKRKzZoIb+66ZypQ+W+HaY3OE= Received: by 10.180.109.228 with SMTP id hv4mr4907290wib.11.1329496615708; Fri, 17 Feb 2012 08:36:55 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id hb10sm37603384wib.10.2012.02.17.08.36.54 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 08:36:54 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3E8225.9030501@FreeBSD.org> Date: Fri, 17 Feb 2012 18:36:53 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Alex Goncharov References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:36:57 -0000 On 02/17/12 18:20, Alex Goncharov wrote: > ,--- You/Freddie (Fri, 17 Feb 2012 08:08:18 -0800) ----* > |> So, how do I go about finding and modifying the sound card pin > |> assignments in FreeBSD 9? (If I can't do it without temporarily > |> installing FreeBSD 8, it would be a huge disappointment. :) > | > | Stick the hint into /boot/loader.conf and reboot. > > How do I find the correct hint if I can't reload the sound module in > the new kernel environment and explore 'dmesg', '/dev/sndstat' and the > physical headphones with the new hint without a reboot? > > Stick something in a file (/boot/device.hints or /boot/loader.conf), > reboot and see if it works... if it doesn't put a different > combination of 'cad', 'nid' and 'seq' and reboot?... And again and > again, till it works?.. Improved HDA driver in HEAD allows to change CODEC configuration via sysctls on fly without unloading. I am going to merge it to 9/8-STABLE in few weeks. If somebody wants to write nice GUI for it -- welcome! ;) -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 16:53:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 554631065672; Fri, 17 Feb 2012 16:53:17 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8508E8FC13; Fri, 17 Feb 2012 16:53:15 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2588606wib.13 for ; Fri, 17 Feb 2012 08:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DVb3bRNlCTewSCzmct7YcxLW5EEDdd0caoC6zps5Xy0=; b=q4EwjJOjSCKXEPcabDGBK3DJmeXi6NL69aR32tZK3RkVSoE2FA2WBni3GhmqPXdu1D 9le1DZOH5hBhSPM+arMQsN0O4tq/zCo6/UfroIehZlgk8wZwcaYrlsdDhB3ZrdAAkfSW dTbU+MNDi0PJw0h87ZjO1sWKeQO70L+3Ca8Ag= MIME-Version: 1.0 Received: by 10.180.101.165 with SMTP id fh5mr4985901wib.10.1329497595150; Fri, 17 Feb 2012 08:53:15 -0800 (PST) Received: by 10.216.73.82 with HTTP; Fri, 17 Feb 2012 08:53:14 -0800 (PST) In-Reply-To: <4F3E807A.60103@FreeBSD.org> References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> Date: Fri, 17 Feb 2012 11:53:14 -0500 Message-ID: From: Arnaud Lacombe To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:53:17 -0000 Hi, On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin wrote: > On 02/15/12 21:54, Jeff Roberson wrote: >> >> On Wed, 15 Feb 2012, Alexander Motin wrote: >>> >>> I've decided to stop those cache black magic practices and focus on >>> things that really exist in this world -- SMT and CPU load. I've >>> dropped most of cache related things from the patch and made the rest >>> of things more strict and predictable: >>> http://people.freebsd.org/~mav/sched.htt34.patch >> >> >> This looks great. I think there is value in considering the other >> approach further but I would like to do this part first. It would be >> nice to also add priority as a greater influence in the load balancing >> as well. > > > I haven't got good idea yet about balancing priorities, but I've rewritten > balancer itself. As soon as sched_lowest() / sched_highest() are more > intelligent now, they allowed to remove topology traversing from the > balancer itself. That should fix double-swapping problem, allow to keep some > affinity while moving threads and make balancing more fair. I did number of > tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 and 16 > threads everything is stationary as it should. With 9 threads I see regular > and random load move between all 8 CPUs. Measurements on 5 minutes run show > deviation of only about 5 seconds. It is the same deviation as I see caused > by only scheduling of 16 threads on 8 cores without any balancing needed at > all. So I believe this code works as it should. > > Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch > > I plan this to be a final patch of this series (more to come :)) and if > there will be no problems or objections, I am going to commit it (except > some debugging KTRs) in about ten days. So now it's a good time for reviews > and testing. :) > is there a place where all the patches are available ? I intend to run some tests on a 1x2x2 (atom D510), 1x4x1 (core-2 quad), and eventually a 2x8x2 platforms, against r231573. Results should hopefully be available by the end of the week-end/middle of next week[0]. - Arnaud [0]: the D510 will likely be testing a couple of Linux kernel over the week-end, and a FreeBSD run takes about 2.5 days to complete. > > -- > Alexander Motin > _______________________________________________ > 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 Fri Feb 17 17:03:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EB3106567A; Fri, 17 Feb 2012 17:03:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63EE68FC15; Fri, 17 Feb 2012 17:03:35 +0000 (UTC) Received: by eekb47 with SMTP id b47so1611391eek.13 for ; Fri, 17 Feb 2012 09:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bfZeMzkLG0oIDlfqlhoIOAhfevEaUC7060gmCGGDGlQ=; b=kdPwOhesRnl3uCEVfpPS+5lW4F+X7ilPEAyR2DzfJPwf3jAeBc5kBbu0KZN77HWymr al8o50UV6O4TDWT0DrCLinwOf4pgUuwJ7Zl6XYhpiL1oM/ogUUdfmNZuVusOC+ceHA6J Xo5fKtwv1EyZFWl8i6R8Q+GdCgOxi7jDA6F/w= Received: by 10.213.35.9 with SMTP id n9mr1262198ebd.106.1329498214338; Fri, 17 Feb 2012 09:03:34 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n52sm40425080eea.5.2012.02.17.09.03.32 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 09:03:33 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3E8858.4000001@FreeBSD.org> Date: Fri, 17 Feb 2012 19:03:20 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Arnaud Lacombe References: <4F2F7B7F.40508@FreeBSD.org> <4F366E8F.9060207@FreeBSD.org> <4F367965.6000602@FreeBSD.org> <4F396B24.5090602@FreeBSD.org> <4F3978BC.6090608@FreeBSD.org> <4F3990EA.1080002@FreeBSD.org> <4F3C0BB9.6050101@FreeBSD.org> <4F3E807A.60103@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Florian Smeets , Jeff Roberson , Andriy Gapon , FreeBSD current Subject: Re: [RFT][patch] Scheduling for HTT and not only X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:03:36 -0000 On 17.02.2012 18:53, Arnaud Lacombe wrote: > On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin wrote: >> On 02/15/12 21:54, Jeff Roberson wrote: >>> On Wed, 15 Feb 2012, Alexander Motin wrote: >>>> I've decided to stop those cache black magic practices and focus on >>>> things that really exist in this world -- SMT and CPU load. I've >>>> dropped most of cache related things from the patch and made the rest >>>> of things more strict and predictable: >>>> http://people.freebsd.org/~mav/sched.htt34.patch >>> >>> This looks great. I think there is value in considering the other >>> approach further but I would like to do this part first. It would be >>> nice to also add priority as a greater influence in the load balancing >>> as well. >> >> I haven't got good idea yet about balancing priorities, but I've rewritten >> balancer itself. As soon as sched_lowest() / sched_highest() are more >> intelligent now, they allowed to remove topology traversing from the >> balancer itself. That should fix double-swapping problem, allow to keep some >> affinity while moving threads and make balancing more fair. I did number of >> tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 and 16 >> threads everything is stationary as it should. With 9 threads I see regular >> and random load move between all 8 CPUs. Measurements on 5 minutes run show >> deviation of only about 5 seconds. It is the same deviation as I see caused >> by only scheduling of 16 threads on 8 cores without any balancing needed at >> all. So I believe this code works as it should. >> >> Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch >> >> I plan this to be a final patch of this series (more to come :)) and if >> there will be no problems or objections, I am going to commit it (except >> some debugging KTRs) in about ten days. So now it's a good time for reviews >> and testing. :) >> > is there a place where all the patches are available ? All my scheduler patches are cumulative, so all you need is only the last mentioned here sched.htt40.patch. But in some cases, especially for multi-socket systems, to let it show its best, you may want to apply additional patch from avg@ to better detect CPU topology: https://gitorious.org/~avg/freebsd/avgbsd/commit/6bca4a2e4854ea3fc275946a023db65c483cb9dd > I intend to run > some tests on a 1x2x2 (atom D510), 1x4x1 (core-2 quad), and eventually > a 2x8x2 platforms, against r231573. Results should hopefully be > available by the end of the week-end/middle of next week[0]. > > [0]: the D510 will likely be testing a couple of Linux kernel over the > week-end, and a FreeBSD run takes about 2.5 days to complete. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 17:10:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08A40106568C for ; Fri, 17 Feb 2012 17:10:33 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id B7EEC8FC0A for ; Fri, 17 Feb 2012 17:10:32 +0000 (UTC) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta07.westchester.pa.mail.comcast.net with comcast id b5AR1i0090bG4ec575AZZy; Fri, 17 Feb 2012 17:10:33 +0000 Received: from hans3 ([66.30.197.229]) by omta03.westchester.pa.mail.comcast.net with comcast id b5AY1i00C4xSlmi3P5AYud; Fri, 17 Feb 2012 17:10:32 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyRKJ-000Ioa-Ec; Fri, 17 Feb 2012 12:10:31 -0500 From: Alex Goncharov To: Alexander Motin In-reply-to: <4F3E8225.9030501@FreeBSD.org> (message from Alexander Motin on Fri, 17 Feb 2012 18:36:53 +0200) References: <4F3E8225.9030501@FreeBSD.org> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 12:10:31 -0500 Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:10:33 -0000 ,--- You/Alexander (Fri, 17 Feb 2012 18:36:53 +0200) ----* | On 02/17/12 18:20, Alex Goncharov wrote: | > How do I find the correct hint if I can't reload the sound module in | > the new kernel environment and explore 'dmesg', '/dev/sndstat' and the | > physical headphones with the new hint without a reboot? | > | > Stick something in a file (/boot/device.hints or /boot/loader.conf), | > reboot and see if it works... if it doesn't put a different | > combination of 'cad', 'nid' and 'seq' and reboot?... And again and | > again, till it works?.. | | Improved HDA driver in HEAD allows to change CODEC configuration via | sysctls on fly without unloading. I am going to merge it to 9/8-STABLE | in few weeks. If somebody wants to write nice GUI for it -- welcome! ;) Being mostly a FreeBSD freeloader (or a marginal contributor), I shouldn't be complaining, and I am not, but permit me to make a personal biased judgment: losing the ability to do a practically important thing (a dynamic sound card tuning) which was available in 8, makes 9 a "not ready to be released" OS (GUI isn't relevant here.) OK, I'll put my upgrades to 9 on hold... Thanks all for clarifying the situation! P.S. As an aside and IMHO: Over the last year, I've been asking myself why I keep bothering with FreeBSD when several Linux distros do everything painlessly out of box. Obviously, I like FreeBSD general structure a lot, that's why. FreeBSD won't miss me going back to Linux, but I may miss FreeBSD, so I am still sticking on, but I see a lot of dangers to FreeBSD being a meaningfully used platform, for various reasons (some of them have been mentioned in several discussions on freebsd-stable.) Breaking POLA in a released OS, which I see with this sound card tuning issue, doesn't add FreeBSD friends... -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 17:19:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE32B106566C for ; Fri, 17 Feb 2012 17:19:48 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5B8B98FC15 for ; Fri, 17 Feb 2012 17:19:48 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2942515wgb.31 for ; Fri, 17 Feb 2012 09:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G82bWlo3zC8XsBOAoXsOjzPItp/iusr1TBlpyJPX9RY=; b=j556jWa2uncQVSKPEWVi/0eo+wWs9TJ+255pRDHU8FYawLDxl8H44GV7vVK/iS30D5 IG9GkGjWsxWc19XRYB3BwPb32HDwbV2vbX159QaQfBaSJ7Tn6b8lpJprA7aFjYVi5ecc BckMv1K7QsufYQLcX7n6XNHrYYOutn8AIkcjY= Received: by 10.180.101.72 with SMTP id fe8mr5174043wib.4.1329499187390; Fri, 17 Feb 2012 09:19:47 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id eq5sm38107909wib.2.2012.02.17.09.19.45 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 09:19:46 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3E8C26.3080900@FreeBSD.org> Date: Fri, 17 Feb 2012 19:19:34 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Alex Goncharov References: <4F3E8225.9030501@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:19:49 -0000 On 17.02.2012 19:10, Alex Goncharov wrote: > ,--- You/Alexander (Fri, 17 Feb 2012 18:36:53 +0200) ----* > | On 02/17/12 18:20, Alex Goncharov wrote: > |> How do I find the correct hint if I can't reload the sound module in > |> the new kernel environment and explore 'dmesg', '/dev/sndstat' and the > |> physical headphones with the new hint without a reboot? > |> > |> Stick something in a file (/boot/device.hints or /boot/loader.conf), > |> reboot and see if it works... if it doesn't put a different > |> combination of 'cad', 'nid' and 'seq' and reboot?... And again and > |> again, till it works?.. > | > | Improved HDA driver in HEAD allows to change CODEC configuration via > | sysctls on fly without unloading. I am going to merge it to 9/8-STABLE > | in few weeks. If somebody wants to write nice GUI for it -- welcome! ;) > > Being mostly a FreeBSD freeloader (or a marginal contributor), I > shouldn't be complaining, and I am not, but permit me to make a > personal biased judgment: losing the ability to do a practically > important thing (a dynamic sound card tuning) which was available in > 8, makes 9 a "not ready to be released" OS (GUI isn't relevant here.) > > OK, I'll put my upgrades to 9 on hold... Thanks all for clarifying the > situation! > > P.S. As an aside and IMHO: > > Over the last year, I've been asking myself why I keep bothering with > FreeBSD when several Linux distros do everything painlessly out of box. > > Obviously, I like FreeBSD general structure a lot, that's why. > FreeBSD won't miss me going back to Linux, but I may miss FreeBSD, so > I am still sticking on, but I see a lot of dangers to FreeBSD being a > meaningfully used platform, for various reasons (some of them have > been mentioned in several discussions on freebsd-stable.) Breaking > POLA in a released OS, which I see with this sound card tuning issue, > doesn't add FreeBSD friends... For many users these days not having sound drivers turned on by default is more astonishing. Luckily most systems don't need hints to get working sound. So it depends on point of view. And definitely I see no problem in this for updating to 9.0, unless you are already biased against it. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 17:43:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6CD81065670 for ; Fri, 17 Feb 2012 17:43:17 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC1C8FC18 for ; Fri, 17 Feb 2012 17:43:16 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta10.westchester.pa.mail.comcast.net with comcast id b5ek1i0031uE5Es5A5jH5h; Fri, 17 Feb 2012 17:43:17 +0000 Received: from hans3 ([66.30.197.229]) by omta16.westchester.pa.mail.comcast.net with comcast id b5jH1i00Z4xSlmi3c5jHqG; Fri, 17 Feb 2012 17:43:17 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyRq0-000Iqy-3l; Fri, 17 Feb 2012 12:43:16 -0500 From: Alex Goncharov To: Alexander Motin In-reply-to: <4F3E8C26.3080900@FreeBSD.org> (message from Alexander Motin on Fri, 17 Feb 2012 19:19:34 +0200) References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 12:43:16 -0500 Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:43:17 -0000 ,--- I/Alex (Fri, 17 Feb 2012 12:10:31 -0500) ----* | Being mostly a FreeBSD freeloader (or a marginal contributor), I | shouldn't be complaining, and I am not, but permit me to make a | personal biased judgment: losing the ability to do a practically | important thing (a dynamic sound card tuning) which was available in | 8, makes 9 a "not ready to be released" OS (GUI isn't relevant here.) | | OK, I'll put my upgrades to 9 on hold... Thanks all for clarifying the | situation! ,--- You/Alexander (Fri, 17 Feb 2012 19:19:34 +0200) ----* | For many users these days not having sound drivers turned on by default | is more astonishing. Perhaps, but the FreeBSD Handbook has been describing the sound setup routine very well (the pin assignment methods I learned from some text you had written -- the man pages or your posts to FreeBSD lists, I don't remember. Thanks for that!) | Luckily most systems don't need hints to get working sound. Based on my experience, I disagree with you -- I had to do it in all the laptops that I installed FreeBSD 8 on (2 -- a low number, but 100% for me)... I never tried to do it with the desktops, but on my laptops, I like listing to music while I work. | So it depends on point of view. And definitely I see no problem in | this for updating to 9.0, unless you are already biased against it. I am not biased against 9, and I will complete the setup of the three systems currently being polished, since there is no point in going back to 8, but I will be unlikely installing 9 on any new system for some number of weeks. A technical question: I have the saved (from 8) copies of /boot/device.hints for the laptops in question which have lines like: hint.hdac.0.cad0.nid22.config="as=1 seq=15 device=Headphones" there. What's the best way to use this in 9? To add to the bottom of /boot/device.hints? Or use in /boot/loader.conf somehow, as was suggested in one of the replies in this thread? If in loader.conf, what's the correct syntax? Again, thank you for the work on the sound cards, documentation and advice! -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 17:56:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56F45106566B for ; Fri, 17 Feb 2012 17:56:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id D12B38FC1D for ; Fri, 17 Feb 2012 17:56:22 +0000 (UTC) Received: by eaan10 with SMTP id n10so1588962eaa.13 for ; Fri, 17 Feb 2012 09:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MsIxdWF/WjooxdsLsN0hwVW65PMV3hMqN0p5Txefv88=; b=bMcUD3DU8Wx6H09iyNf+gVXzeZRMMtMjgO0+hb7+8WOlYutDjkLDAmRLVVyAi9V140 Kp8RAH9rIXEpyk+4c8S5iRyBrrjG4Z74jrtaY02ORZZsObMZTaoklWDRpsi4nwuDwLSU gPe6dfIoCJJ9RbxGyOeHhcMRqRZeyWWBojyts= Received: by 10.14.94.66 with SMTP id m42mr4099092eef.66.1329501381675; Fri, 17 Feb 2012 09:56:21 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id c16sm40975860eei.1.2012.02.17.09.56.20 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 09:56:20 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3E94C2.9020201@FreeBSD.org> Date: Fri, 17 Feb 2012 19:56:18 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Alex Goncharov References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:56:23 -0000 On 02/17/12 19:43, Alex Goncharov wrote: > A technical question: I have the saved (from 8) copies of > /boot/device.hints for the laptops in question which have lines like: > > hint.hdac.0.cad0.nid22.config="as=1 seq=15 device=Headphones" > > there. > > What's the best way to use this in 9? To add to the bottom of > /boot/device.hints? Or use in /boot/loader.conf somehow, as was > suggested in one of the replies in this thread? If in loader.conf, > what's the correct syntax? I am not ready to tell you which way is more correct in theory, because in practice all of them are working. I personally prefer to have everything set in my /boot/loader.conf. The syntax is equal. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 17:49:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D27106564A for ; Fri, 17 Feb 2012 17:49:21 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id D870E8FC1C for ; Fri, 17 Feb 2012 17:49:20 +0000 (UTC) Date: Fri, 17 Feb 2012 18:49:17 +0100 From: vermaden To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org X-Mailer: interia.pl/pf09 X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329500958; bh=SryWECdGWvUbfmxaVo93dEJ0eU2ybjVooud7hOM6YHo=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FA14eL5cVhvKO1viBUZ89uN/5Y3h9VFU7kDefeztMNaxlM6Jj9iV9bD7OrkRV13dA teELeG2V14Y5AK3mxYk4KSiClCxc8S+BHXHmm5tOoVfvwWwnuGYFfyc1R00n8RbJx7 pylQOH1fh0260qTnhKwWx/VW5IhSugFRQjaT4DDE= X-Mailman-Approved-At: Fri, 17 Feb 2012 18:06:06 +0000 Cc: Subject: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:49:21 -0000 Hi, I have finally made some effort on writing flexible yet very simple automou= nter for FreeBSD desktop. Feel free to submit me BUG reports ;) It currently supports these file formats: -- NTFS(rw) requires [port]sysutils/fusefs-ntfs[/port] -- FAT/FAT32 -- exFAT requires [port]sysutils/fusefs-exfat[/port] -- EXT2 -- EXT3 -- EXT4 requires [port]sysutils/fusefs-ext4fuse[/port] -- UFS (DOH!) It keeps state of the mounted devices at /var/run/automount.state and logs = all activities to /var/log/automount.log file. The place for the script is at /usr/local/sbin/automount.sh executable. The only additional configuration it requires are those lines at the end of= /etc/devd.conf file along with restarting /etc/rc.d/devd daemon. notify 200 { match "system" "DEVFS"; match "type" "CREATE"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev attach"; }; notify 200 { match "system" "DEVFS"; match "type" "DESTROY"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev detach"; }; The /usr/local/sbin/automount.sh executable is here: #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ LINE=3D$( grep -n -E "${1}$" ${2} | cut -d : -f 1 ) sed -i '' ${3}d ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} ) in (*NTFS*) __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" ;; (*FAT*) __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -o longnames -l -L pl_PL.ISO8859-2 -D cp85= 2 ${I} ${MNT} __log "${I}:mount (fat)" ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${O} count=3D1 | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep " ${MNT} " | awk '{printf $1}' ) ${M= NT} done ;; (detach) MOUNTED=3D$( mount ) __state_lock while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNTED}" | grep -E "^${PROVIDER} " | awk '{print= $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done < ${STATE} __state_unlock __log "/dev/${1}:detach" ;; esac PS. Below are links for 'mirror' threads. http://forums.freebsd.org/showthread.php?t=3D29895 http://daemonforums.org/showthread.php?t=3D6838 Regards, vermaden --- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 18:39:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3045C1065677 for ; Fri, 17 Feb 2012 18:39:33 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id CA71D8FC0C for ; Fri, 17 Feb 2012 18:39:32 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id b4ln1i0041vXlb8516fZu1; Fri, 17 Feb 2012 18:39:33 +0000 Received: from hans3 ([66.30.197.229]) by omta17.westchester.pa.mail.comcast.net with comcast id b6fY1i00J4xSlmi3d6fYkQ; Fri, 17 Feb 2012 18:39:33 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RySiR-000Iwl-DD; Fri, 17 Feb 2012 13:39:31 -0500 From: Alex Goncharov To: Alexander Motin In-reply-to: <4F3E94C2.9020201@FreeBSD.org> (message from Alexander Motin on Fri, 17 Feb 2012 19:56:18 +0200) References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3E94C2.9020201@FreeBSD.org> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 13:39:31 -0500 Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 18:39:33 -0000 ,--- You/Alexander (Fri, 17 Feb 2012 19:56:18 +0200) ----* | On 02/17/12 19:43, Alex Goncharov wrote: | > A technical question: I have the saved (from 8) copies of | > /boot/device.hints for the laptops in question which have lines like: | > ... | > What's the best way to use this in 9? To add to the bottom of | > /boot/device.hints? Or use in /boot/loader.conf somehow? | | I am not ready to tell you which way is more correct in theory, because | in practice all of them are working. I personally prefer to have | everything set in my /boot/loader.conf. The syntax is equal. OK, I've never done it before, but now I added the "hint.hdac...." line to /boot/loader.conf, instead of device.hints (and I commented out snd_hda_load="YES" there). Rebooted, plugged in the headphones: the sound goes there all right. Thank you for your help! -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 19:09:59 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90A3B106566C; Fri, 17 Feb 2012 19:09:59 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2B98FC1A; Fri, 17 Feb 2012 19:09:59 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so4571902pbc.13 for ; Fri, 17 Feb 2012 11:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=09lK6KVgZgYtbYLf4BJ+ADLx9C9Fk7Xl8EXM6HgwkY4=; b=G9k6RpI+btOTgSJkuccIYAddzZi7Xih/xd1ZyRvW+7mdq1PgURDVuSJhe4vGPBygvb MRIzvCw2MR2wtYDhG1VgKrvG/xlbEg7ZMLvLRSSR9+8hHcHF4O3kEoX7Hxc3TjrN2C/R EZnSjiWx6lbdrtT2Y2vDvPbqDHJEj6EEnXr/4= MIME-Version: 1.0 Received: by 10.68.223.68 with SMTP id qs4mr26652490pbc.112.1329504344134; Fri, 17 Feb 2012 10:45:44 -0800 (PST) Received: by 10.68.48.35 with HTTP; Fri, 17 Feb 2012 10:45:44 -0800 (PST) In-Reply-To: <4F3C275F.9070808@shadowsun.net> References: <4F3C275F.9070808@shadowsun.net> Date: Fri, 17 Feb 2012 13:45:44 -0500 Message-ID: From: Super Bisquit To: Eric McCorkle Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: CUDA porting effort? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:09:59 -0000 I'd be willing to try building it on the Power(PC) platform. On Wed, Feb 15, 2012 at 4:45 PM, Eric McCorkle wrote: > Given that NVidia is releasing the CUDA platform source on a limited > basis, is anyone actively working to port it to FreeBSD? The reason I > ask is that to get access to the source, you have to submit a request > explaining what you intend to use it for. It might be a good idea to > get ahold of the source on behalf of FreeBSD, so that interested people > could work on porting it. I could devote a small amount of time to such > an effort; I'm wondering if there's interest from anyone else. > > From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 19:10:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C285106566B; Fri, 17 Feb 2012 19:10:45 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE2388FC13; Fri, 17 Feb 2012 19:10:41 +0000 (UTC) Received: by daec6 with SMTP id c6so4039048dae.13 for ; Fri, 17 Feb 2012 11:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=8NM61RvHpd0nco08UFmTT4EB20SvX+G3fLQ7K5EfR5o=; b=NHm7jDsaTO1kAUnrsWvsS4kdTp+5SvxRoabStLLd3BXv0QZmv1WSN8855LE8+TgACi wgWAHmdguoLlLRxw3vORuZdoH/kxslsxnAZ5zxcBPecYiXMsKFlBfyqPA/VNbBkNxnj4 GchrFTl9Ij0GubRYpM2FZ5A3MRWUb/QxOrot8= Received: by 10.68.219.136 with SMTP id po8mr11829642pbc.39.1329505841597; Fri, 17 Feb 2012 11:10:41 -0800 (PST) Received: from bakeneko.local ([75.101.87.90]) by mx.google.com with ESMTPS id t10sm17387181pbb.18.2012.02.17.11.10.39 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 11:10:40 -0800 (PST) Message-ID: <4F3EA5F2.9070804@gmail.com> Date: Fri, 17 Feb 2012 11:09:38 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Alex Goncharov References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alexander Motin Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:10:45 -0000 On 02/17/12 09:43, Alex Goncharov wrote: > ,--- I/Alex (Fri, 17 Feb 2012 12:10:31 -0500) ----* > | Being mostly a FreeBSD freeloader (or a marginal contributor), I > | shouldn't be complaining, and I am not, but permit me to make a > | personal biased judgment: losing the ability to do a practically > | important thing (a dynamic sound card tuning) which was available in > | 8, makes 9 a "not ready to be released" OS (GUI isn't relevant here.)= > |=20 > | OK, I'll put my upgrades to 9 on hold... Thanks all for clarifying th= e > | situation! > ,--- You/Alexander (Fri, 17 Feb 2012 19:19:34 +0200) ----* > | For many users these days not having sound drivers turned on by defau= lt=20 > | is more astonishing. > > Perhaps, but the FreeBSD Handbook has been describing the sound setup > routine very well (the pin assignment methods I learned from some text > you had written -- the man pages or your posts to FreeBSD lists, I > don't remember. Thanks for that!) > > | Luckily most systems don't need hints to get working sound. > > Based on my experience, I disagree with you -- I had to do it in all > the laptops that I installed FreeBSD 8 on (2 -- a low number, but 100% > for me)... I never tried to do it with the desktops, but on my > laptops, I like listing to music while I work. > > | So it depends on point of view. And definitely I see no problem in > | this for updating to 9.0, unless you are already biased against it. > > I am not biased against 9, and I will complete the setup of the three > systems currently being polished, since there is no point in going > back to 8, but I will be unlikely installing 9 on any new system for > some number of weeks. > > A technical question: I have the saved (from 8) copies of > /boot/device.hints for the laptops in question which have lines like: > > hint.hdac.0.cad0.nid22.config=3D"as=3D1 seq=3D15 device=3DHeadphones"= > > there. > > What's the best way to use this in 9? To add to the bottom of > /boot/device.hints? Or use in /boot/loader.conf somehow, as was > suggested in one of the replies in this thread? If in loader.conf, > what's the correct syntax? > > Again, thank you for the work on the sound cards, documentation and > advice! > > -- Alex -- alex-goncharov@comcast.net -- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" For what it's worth, it's just a change in GENERIC. It's not hard to compile a kernel with different options, just like linux. Does a Redhat, or Ubuntu kernel meet everyone's need without recompiling or issues? Never. I run both, I'm not trying to start a flamewar. So recompile GENERIC without snd_hda, you're a power user. The handbook is an excellent resource if you've never done it. It's actually nice to have a minimal kernel config available for any kind of testing. Or reboot a few times, it's not that bad! Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 19:23:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21164106566B; Fri, 17 Feb 2012 19:23:34 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E23428FC0C; Fri, 17 Feb 2012 19:23:33 +0000 (UTC) Received: by daec6 with SMTP id c6so4051412dae.13 for ; Fri, 17 Feb 2012 11:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=JNFCrQKGrkaT1LY0zYq/eN319AXX8rey1lu3yYTaYZQ=; b=MoX1KzhH+plgWobF+Nz896L4FMbcA7TamsH03huceeQmaopzTEjNM16kbUsyfDG2Gs sybStFNFrgDWTIW0v5SrQNWbt/fHpsp8raUwRLPzDiMqvLjABnjfqU2IS9nWtXYb7Y2i SPTk/3h0Sh5jVRMaz6OFWqPHtgeYDVmZ7QLyM= Received: by 10.68.224.2 with SMTP id qy2mr27166201pbc.48.1329506613481; Fri, 17 Feb 2012 11:23:33 -0800 (PST) Received: from bakeneko.local ([75.101.87.90]) by mx.google.com with ESMTPS id k2sm5857682pba.28.2012.02.17.11.23.31 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 11:23:32 -0800 (PST) Message-ID: <4F3EA8F6.6040702@gmail.com> Date: Fri, 17 Feb 2012 11:22:30 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: vermaden References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:23:34 -0000 On 02/17/12 09:49, vermaden wrote: > Hi, > > I have finally made some effort on writing flexible yet very simple aut= omounter for FreeBSD desktop. > > Feel free to submit me BUG reports ;) > > It currently supports these file formats: > -- NTFS(rw) requires [port]sysutils/fusefs-ntfs[/port] > -- FAT/FAT32 > -- exFAT requires [port]sysutils/fusefs-exfat[/port] > -- EXT2 > -- EXT3 > -- EXT4 requires [port]sysutils/fusefs-ext4fuse[/port] > -- UFS (DOH!) > > It keeps state of the mounted devices at /var/run/automount.state and l= ogs all activities to /var/log/automount.log file. > > The place for the script is at /usr/local/sbin/automount.sh executable.= > > The only additional configuration it requires are those lines at the en= d of /etc/devd.conf file along with restarting /etc/rc.d/devd daemon. > > notify 200 { > match "system" "DEVFS"; > match "type" "CREATE"; > match "cdev" "(da|mmcsd)[0-9]+"; > action "/usr/local/sbin/automount.sh $cdev attach"; > }; > > notify 200 { > match "system" "DEVFS"; > match "type" "DESTROY"; > match "cdev" "(da|mmcsd)[0-9]+"; > action "/usr/local/sbin/automount.sh $cdev detach"; > }; > > The /usr/local/sbin/automount.sh executable is here: > > #! /bin/sh > > PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin > LOG=3D"/var/log/automount.log" > STATE=3D"/var/run/automount.state" > DATEFMT=3D"%Y-%m-%d %H:%M:%S" > > __create_mount_point() { # /* 1=3DDEV */ > MNT=3D"/mnt/$( basename ${1} )" > mkdir -p ${MNT} > } > > __state_lock() { > while [ -f ${STATE}.lock ]; do sleep 0.5; done > :> ${STATE}.lock > } > > __state_unlock() { > rm ${STATE}.lock > } > > __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ > __state_lock > echo "${1} ${2} ${3}" >> ${STATE} > __state_unlock > } > > __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ > LINE=3D$( grep -n -E "${1}$" ${2} | cut -d : -f 1 ) > sed -i '' ${3}d ${2} > } > > __log() { # /* @=3DMESSAGE */ > echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} > } > > case ${2} in > (attach) > for I in /dev/${1}* > do > case $( file -L -s ${I} ) in > (*NTFS*) > __create_mount_point ${I} > ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ > __log "${I}:mount (ntfs)" > ;; > (*FAT*) > __create_mount_point ${I} > fsck_msdosfs -y ${I} > mount_msdosfs -o large -o longnames -l -L pl_PL.ISO8859-2 -D = cp852 ${I} ${MNT} > __log "${I}:mount (fat)" > ;; > (*ext2*) > __create_mount_point ${I} > fsck.ext2 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext2)" > ;; > (*ext3*) > __create_mount_point ${I} > fsck.ext3 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext3)" > ;; > (*ext4*) > __create_mount_point ${I} > fsck.ext4 -y ${I} > ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ > __log "${I}:mount (ext4)" > ;; > (*Unix\ Fast\ File*) > __create_mount_point ${I} > fsck_ufs -y ${I} > mount ${I} ${MNT} > __log "${I}:mount (ufs)" > ;; > (*) > case $( dd < ${O} count=3D1 | strings | head -1 ) in > (EXFAT) > __create_mount_point ${I} > mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ > __log "${I}:mount (ufs)" > ;; > (*) continue ;; > esac > ;; > esac > __state_add ${I} $( mount | grep " ${MNT} " | awk '{printf $1}' )= ${MNT} > done > ;; > > (detach) > MOUNTED=3D$( mount ) > __state_lock > while read DEV PROVIDER MNT > do > TARGET=3D$( echo "${MOUNTED}" | grep -E "^${PROVIDER} " | awk '{p= rint $3}' ) > [ -z ${TARGET} ] && { > __state_remove ${MNT} ${STATE} ${LINE} > continue > } > umount -f ${TARGET} & > unset TARGET > __state_remove ${MNT} ${STATE} ${LINE} > __log "${DEV}:umount" > done < ${STATE} > __state_unlock > __log "/dev/${1}:detach" > ;; > > esac > > > PS. Below are links for 'mirror' threads. > http://forums.freebsd.org/showthread.php?t=3D29895 > http://daemonforums.org/showthread.php?t=3D6838 > > Regards, > vermaden > > > > > > > > > > > > > > > > > > > > > > > > > --- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" Some things to consider/test: How do I set custom flags, like nosuid,noatime,nodev,noexec,async (or sync) for mounts? What if make a usb drive with an illegal name, existing name or other dangerous values? Can I use the automounter to either mount over another mount to impersonate it, or can I overwrite arbitrary files or directories? Some of these above things don't work on Linux with udev (i.e. gnome-vfs automount gets some fairly generous flags automatically) I didn't get a chance to test some of the naming things on Linux either, as many drive formatting programs validate the name. Something to consider, Matt Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 19:34:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94581065673 for ; Fri, 17 Feb 2012 19:34:41 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF308FC14 for ; Fri, 17 Feb 2012 19:34:40 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id b58S1i01g1vXlb85B7ahWX; Fri, 17 Feb 2012 19:34:41 +0000 Received: from hans3 ([66.30.197.229]) by omta17.westchester.pa.mail.comcast.net with comcast id b7ah1i00P4xSlmi3d7ahkC; Fri, 17 Feb 2012 19:34:41 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyTZo-000J0R-0Y; Fri, 17 Feb 2012 14:34:40 -0500 From: Alex Goncharov To: matt In-reply-to: <4F3EA5F2.9070804@gmail.com> (message from matt on Fri, 17 Feb 2012 11:09:38 -0800) References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 14:34:40 -0500 Cc: freebsd-hackers@freebsd.org, mav@FreeBSD.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:34:41 -0000 ,--- You/matt (Fri, 17 Feb 2012 11:09:38 -0800) ----* | For what it's worth, it's just a change in GENERIC. It's not hard to | compile a kernel with different options, That's what I've been doing for years, with e.g. # options INET6 # IPv6 communications protocols # device cbb # cardbus (yenta) bridge # device pccard # PC Card (16-bit) bus # device cardbus # CardBus (32-bit) bus in my kernel configuration on 8; there was no snd_hda there, and this is why I asked about the possibly new kernel modularization in 9. | So recompile GENERIC without snd_hda, you're a power user. Yes, I see it in 9 now: uname -sr; grep -iE 'snd|hda' /usr/src/sys/amd64/conf/GENERIC => FreeBSD 8.2-STABLE uname -sr; grep -iE 'snd|hda' /usr/src/sys/amd64/conf/GENERIC => FreeBSD 9.0-STABLE device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_uaudio # USB Audio device snd_via8233 # VIA VT8233x Audio The presence of /boot/kernel/snd_hda.ko in 9 did confuse me. | The handbook is an excellent resource if you've never done it. It's | actually nice to have a minimal kernel config available for any kind | of testing. Or reboot a few times, it's not that bad! That's another thing for me to decide on: as I said, I used to eliminate building some parts of the kernel but have recently decided that it might be easier to just use GENERIC -- the resources and sizes are no longer worth worrying about. I have a better understanding of the situation now and will do some adjustments. Thanks, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 19:46:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED5D2106566C; Fri, 17 Feb 2012 19:46:37 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id B0C9A8FC12; Fri, 17 Feb 2012 19:46:37 +0000 (UTC) Received: by daec6 with SMTP id c6so4072807dae.13 for ; Fri, 17 Feb 2012 11:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=486lRFegiOiC2q5+/o2NFhSnrIYZR8P8YNocsXmkNCw=; b=veizdW/fZ5J3AZ3+QZXTBhv7dxDX3TQw4V7OiBPZhvG8brQ4fcgzgBpChNvKlenDl2 uc2gWK9z71V64JLh/ibZVi11yi4Ncc8jzNv53VwNetNON08rQhRfQdTHkPMgplJ+ehjw /xfcv5wFUZQrXpSJZ7C/rcK8ai8FnwzZUetLg= Received: by 10.68.213.232 with SMTP id nv8mr21805332pbc.155.1329507997550; Fri, 17 Feb 2012 11:46:37 -0800 (PST) Received: from bakeneko.local (adsl-67-118-230-86.dsl.pltn13.pacbell.net. [67.118.230.86]) by mx.google.com with ESMTPS id ld17sm5900508pbb.37.2012.02.17.11.46.35 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 11:46:36 -0800 (PST) Message-ID: <4F3EAE5F.6070903@gmail.com> Date: Fri, 17 Feb 2012 11:45:35 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Alex Goncharov References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, mav@FreeBSD.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 19:46:38 -0000 On 02/17/12 11:34, Alex Goncharov wrote: > ,--- You/matt (Fri, 17 Feb 2012 11:09:38 -0800) ----* > | For what it's worth, it's just a change in GENERIC. It's not hard to > | compile a kernel with different options, > > That's what I've been doing for years, with e.g. > > # options INET6 # IPv6 communications protocols > # device cbb # cardbus (yenta) bridge > # device pccard # PC Card (16-bit) bus > # device cardbus # CardBus (32-bit) bus > > in my kernel configuration on 8; there was no snd_hda there, and this > is why I asked about the possibly new kernel modularization in 9. > > | So recompile GENERIC without snd_hda, you're a power user. > > Yes, I see it in 9 now: > > uname -sr; grep -iE 'snd|hda' /usr/src/sys/amd64/conf/GENERIC > =3D> > FreeBSD 8.2-STABLE > =20 > uname -sr; grep -iE 'snd|hda' /usr/src/sys/amd64/conf/GENERIC > =3D> > FreeBSD 9.0-STABLE > device snd_es137x # Ensoniq AudioPCI ES137x > device snd_hda # Intel High Definition Audio > device snd_ich # Intel, NVidia and other ICH AC'97= > Audio > device snd_uaudio # USB Audio > device snd_via8233 # VIA VT8233x Audio > > The presence of /boot/kernel/snd_hda.ko in 9 did confuse me. > > | The handbook is an excellent resource if you've never done it. It's > | actually nice to have a minimal kernel config available for any kind > | of testing. Or reboot a few times, it's not that bad! > > That's another thing for me to decide on: as I said, I used to > eliminate building some parts of the kernel but have recently decided > that it might be easier to just use GENERIC -- the resources and sizes > are no longer worth worrying about. > > I have a better understanding of the situation now and will do some > adjustments. > > Thanks, > > -- Alex -- alex-goncharov@comcast.net -- > Sorry, I didn't send my reply until after you had written that you used to modify the kernel. I understand the value in sticking with generic...I've always had machines that needed something added or removed for best function. Given that there's apparently little penalty for module vs. kernel, I can see not including it by default in GENERIC. I do have a laptop that won't make console tones unless snd_hda is NOT loaded, which is odd, but never worth debugging. Thinking bigger picture (beyond sound), would it make sense to keep GENERIC very minimal, but provide an extensive loader.conf with a default install...so most things worked, but were loaded as modules? Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 20:14:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9538E1065675 for ; Fri, 17 Feb 2012 20:14:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0441D8FC0C for ; Fri, 17 Feb 2012 20:14:37 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so3070498wgb.31 for ; Fri, 17 Feb 2012 12:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CR+Ue2y8j2I7kPac7uvMCwm3iAeRTZcu3n30E9fNX5Y=; b=tVKS6W39QC0xDvjAbeHFXnzENLp8V6kz0nwsNJgreRmyQbkNKNBY1BQ6CiqLeaBknr z0EcFQJSDlz7ryX7wBsBgpoXOuDVtl7KDwcxdvtO5t/tHYrvB48eS9LnkIiukUQ2XQ8S a6/mfAc1XM/HoPwKQ5LHrFIpxxPFRhPGfV5Y4= MIME-Version: 1.0 Received: by 10.180.86.198 with SMTP id r6mr204250wiz.22.1329509676994; Fri, 17 Feb 2012 12:14:36 -0800 (PST) Received: by 10.180.106.129 with HTTP; Fri, 17 Feb 2012 12:14:36 -0800 (PST) In-Reply-To: References: <201111081005.43851.jhb@freebsd.org> Date: Fri, 17 Feb 2012 15:14:36 -0500 Message-ID: From: Ryan Stone To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:14:38 -0000 On Wed, Feb 15, 2012 at 10:20 PM, Vijay Singh wrote: > I hit the assert in line 405. So right after locking Giant, it is > found unlocked!!! Try running kldload/kldunload with INVARIANTS enabled. I would suspect that you're hitting a case where the kldload code is unlocking Giant when it doesn't own it. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 20:19:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420FE106566B for ; Fri, 17 Feb 2012 20:19:33 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 973D98FC0C for ; Fri, 17 Feb 2012 20:19:32 +0000 (UTC) Received: by werm13 with SMTP id m13so3271143wer.13 for ; Fri, 17 Feb 2012 12:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=btH2bTxVH1aleKItKzyA51NF4U2lR76v2j+J7l3kIVY=; b=ByZoiOYHn7StrhaPMp3RX9RfAbGo29lUT/ToAr3ssU/Pm9jLmfkYtN03KLgw9LcosK 5ViBa2cNW+pMpXZiv0YubQ3k86pRGrx7oYnHpUiiIwj3Suh3fD1af5N3fc38aZ9esvBu U1uKO5CYu0qiSzPyUsAaZ5zcZkuPDcZsGZtQ4= MIME-Version: 1.0 Received: by 10.216.145.207 with SMTP id p57mr3873361wej.29.1329509971435; Fri, 17 Feb 2012 12:19:31 -0800 (PST) Received: by 10.180.106.129 with HTTP; Fri, 17 Feb 2012 12:19:31 -0800 (PST) In-Reply-To: References: <201111081005.43851.jhb@freebsd.org> Date: Fri, 17 Feb 2012 15:19:31 -0500 Message-ID: From: Ryan Stone To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:19:33 -0000 On Fri, Feb 17, 2012 at 3:14 PM, Ryan Stone wrote: > On Wed, Feb 15, 2012 at 10:20 PM, Vijay Singh wro= te: >> I hit the assert in line 405. So right after locking Giant, it is >> found unlocked!!! > > Try running kldload/kldunload with INVARIANTS enabled. =A0I would > suspect that you're hitting a case where the kldload code is unlocking > Giant when it doesn't own it. Wait, never mind, you're already running with INVARIANTS. In that case I have no idea. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 20:41:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DC4F1065672; Fri, 17 Feb 2012 20:41:09 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7058FC1D; Fri, 17 Feb 2012 20:41:08 +0000 (UTC) Date: Fri, 17 Feb 2012 21:41:06 +0100 From: vermaden To: matt X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EA8F6.6040702@gmail.com> References: <4F3EA8F6.6040702@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329511266; bh=ngddleKd97CoYvRfe/1NV/RUwArZ3nb7wf7lqdu+V/w=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=RJLtUwqxMALnXxOW9du9hD7jxHYCXkE7UFDX1H8B/Y37WXioL9E9iOe5zANpBL9cX RpwBkuUmh/8D7Z9t07+kwzvX3zzc/Dp3Cdx/4yf1kyt5BcmveOB5DpzAv9bnX4RSWv fcU4E/wpXU9MoIrB/KzxzkracUPuqT+lgBhTmIcg= X-Mailman-Approved-At: Fri, 17 Feb 2012 20:47:59 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:41:09 -0000 I already made some changes for the 'better' ... Here is the latest version: #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}$" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} ) in (*NTFS*) __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" ;; (*FAT*) __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -o longnames -l -L pl_PL.ISO8859-2 -D cp85= 2 ${I} ${MNT} __log "${I}:mount (fat)" ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${O} count=3D1 | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep " ${MNT} " | awk '{printf $1}' ) ${M= NT} || continue done ;; (detach) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( mount | grep -E "^${PROVIDER} " | awk '{print $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" ;; esac I have made tests with 3 different USB drives, with different and same fail= esystems, connecting them all at once, disconnecting all at once, random co= nnect, disconnect etc. Currently it seems to work ok but suggestions are very welcome. > Some things to consider/test: >=20 > How do I set custom flags, like nosuid,noatime,nodev,noexec,async (or > sync) for mounts? Currently You can add these options to filesystem specific mount command, b= ut its definitely possible. > What if make a usb drive with an illegal name, existing name or other dan= gerous values? The filesystem label is not used at all, I just use device names, which are= reported by FreeBSD, so quite bulletproof here and then create appreciate = /mnt/da0s1 directories. > Can I use the automounter to either mount over another mount to > impersonate it, or can I overwrite arbitrary files or directories? I have done everything to check that and to omit that, if not, then submit = a BUG ;) Thanks for suggestions Matt. Regards, vermaden --=20 ... From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 21:00:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F104106564A for ; Fri, 17 Feb 2012 21:00:46 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2108FC12 for ; Fri, 17 Feb 2012 21:00:45 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id b8xW1i00527AodY5790lk5; Fri, 17 Feb 2012 21:00:45 +0000 Received: from hans3 ([66.30.197.229]) by omta19.westchester.pa.mail.comcast.net with comcast id b90l1i00F4xSlmi3f90lT3; Fri, 17 Feb 2012 21:00:45 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyUv6-000J5e-0E; Fri, 17 Feb 2012 16:00:44 -0500 From: Alex Goncharov To: matt In-reply-to: <4F3EAE5F.6070903@gmail.com> (message from matt on Fri, 17 Feb 2012 11:45:35 -0800) References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 16:00:44 -0500 Cc: freebsd-hackers@freebsd.org, mav@FreeBSD.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:00:46 -0000 ,--- You/matt (Fri, 17 Feb 2012 11:45:35 -0800) ----* | Given that there's apparently little penalty for module vs. kernel, | I can see not including it by default in GENERIC. I do have a | laptop that won't make console tones unless snd_hda is NOT loaded, | which is odd, but never worth debugging. | | Thinking bigger picture (beyond sound), would it make sense to keep | GENERIC very minimal, but provide an extensive loader.conf with a | default install...so most things worked, but were loaded as modules? For me as a user, that would be a much preferable approach, instilled long ago by Linux. I don't like unused stuff around, and I like to understand what I am using. Some build kernel confutation parameters "minimum modules", "medium modules", "maximum modules" might be utilized. I would be using "medium" or most likely "maximum", leaving me with a minimal kernel. -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 21:58:28 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EE01106566C; Fri, 17 Feb 2012 21:58:28 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id F41508FC0A; Fri, 17 Feb 2012 21:58:27 +0000 (UTC) Received: by yenl12 with SMTP id l12so2404407yen.13 for ; Fri, 17 Feb 2012 13:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cx5hsnSQh7a+HnZ+GHgxw3fLg5TAmpF+IsdqwkkpxUg=; b=RFoYaVqvKMHLDa3g2gp8ryXooMDLeNzl572C0r6V3Gl71wY26kkBQGRTneBvKUxU97 C45hM4UNzJp1s+vvEuNVogwSSnwntP95rKx+MCRTIzmNzr8d45XUEebR0od6Z+kjptz4 2PA9G6U18srS22bHsiLtR/ODyz6gM62gnK9Ac= MIME-Version: 1.0 Received: by 10.236.148.143 with SMTP id v15mr11820618yhj.47.1329514446937; Fri, 17 Feb 2012 13:34:06 -0800 (PST) Received: by 10.236.22.138 with HTTP; Fri, 17 Feb 2012 13:34:06 -0800 (PST) In-Reply-To: <4F3C275F.9070808@shadowsun.net> References: <4F3C275F.9070808@shadowsun.net> Date: Fri, 17 Feb 2012 22:34:06 +0100 Message-ID: From: Oliver Pinter To: Eric McCorkle Content-Type: text/plain; charset=ISO-8859-1 Cc: "O. Hartmann" , hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: CUDA porting effort? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:58:28 -0000 CC: Oliver Hartmann On 2/15/12, Eric McCorkle wrote: > Given that NVidia is releasing the CUDA platform source on a limited > basis, is anyone actively working to port it to FreeBSD? The reason I > ask is that to get access to the source, you have to submit a request > explaining what you intend to use it for. It might be a good idea to > get ahold of the source on behalf of FreeBSD, so that interested people > could work on porting it. I could devote a small amount of time to such > an effort; I'm wondering if there's interest from anyone else. > > From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 22:08:04 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C881065670 for ; Fri, 17 Feb 2012 22:08:04 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 738F78FC08 for ; Fri, 17 Feb 2012 22:08:04 +0000 (UTC) Received: by eaan10 with SMTP id n10so1653738eaa.13 for ; Fri, 17 Feb 2012 14:08:03 -0800 (PST) Received-SPF: pass (google.com: domain of rank1seeker@gmail.com designates 10.14.127.80 as permitted sender) client-ip=10.14.127.80; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rank1seeker@gmail.com designates 10.14.127.80 as permitted sender) smtp.mail=rank1seeker@gmail.com; dkim=pass header.i=rank1seeker@gmail.com Received: from mr.google.com ([10.14.127.80]) by 10.14.127.80 with SMTP id c56mr5673584eei.13.1329516483428 (num_hops = 1); Fri, 17 Feb 2012 14:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=SppfNV/6fSitZlWTiMTBSfBSdPq5mhprH8kmoBntQ6E=; b=CEZ+ZaTA9UT18pq9BWPMl77gwnP3NH5QkZ+p9F5PAhO6mUnbXFACJ2/HgMCIDI3b9G D74t8YM4eKQ0w+SCcQBDSYI5qYznYf8qWqoaceBbmSd+JpUzWdKia6RKSTJr96tW9/qk 01XqlTiSJTTitb3a0YbFxmfTqDWWthjiSOmfY= Received: by 10.14.127.80 with SMTP id c56mr4603748eei.13.1329516483377; Fri, 17 Feb 2012 14:08:03 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id n17sm43436872eei.3.2012.02.17.14.08.01 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 14:08:02 -0800 (PST) Message-ID: <20120217.220802.988.2@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Fri, 17 Feb 2012 23:08:02 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 22:08:05 -0000 > For me as a user, that would be a much preferable approach, = instilled=0D=0A> long ago by Linux. I don't like unused stuff around, and = I like to=0D=0A> understand what I am using.=0D=0A> =0D=0A> Some build = kernel confutation parameters "minimum modules", "medium=0D=0A> modules", = "maximum modules" might be utilized. I would be using=0D=0A> "medium" or = most likely "maximum", leaving me with a minimal kernel.=0D=0A> =0D=0A> = -- Alex -- alex-goncharov@comcast.net --=0D=0A=0D=0ANO.=0D=0A=0D=0A> = Thinking bigger picture (beyond sound), would it make sense to = keep=0D=0A> GENERIC very minimal, but provide an extensive loader.conf = with a=0D=0A> default install...so most things worked, but were loaded as = modules?=0D=0A> =0D=0A> Matt=0D=0A=0D=0ANO.=0D=0A=0D=0A=0D=0AYou can't = base a "wish" on a solution for YOURS problems!=0D=0A=0D=0AGENERIC must = be as giantic as possible, to make as many machines as possible to BOOT = and enable all what can be enabled in/on them.=0D=0ATHEN ... individual = "strips" unhooked parts -> custom kernel, via wich you "specialize it", = for your hardware!=0D=0A=0D=0AThat is, unless individual is passive/bored = (lazy?) and prefer everything on a silver plate ...=0D=0AThere are many = paths in that case ...=0D=0AWindows are the easiest solution. THEY THINK = FOR YOU!=0D=0A;)=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 21:59:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5BE1065678; Fri, 17 Feb 2012 21:59:07 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id F39708FC1B; Fri, 17 Feb 2012 21:59:06 +0000 (UTC) Date: Fri, 17 Feb 2012 22:59:05 +0100 From: vermaden To: freebsd-stable@FreeBSD.org X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EA8F6.6040702@gmail.com> References: <4F3EA8F6.6040702@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329515945; bh=iwBGyDJMPyb9jofdjq5ClTzYd0zr8nKvv2w/c4zui+0=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=mLvHmePOdr69MXFVHNHlh4J4VnpUte6qP/lTaCOMBNOBH1OcKlkpVibczySgd1Smt tvNbDFXsFHVhYijYrFJCJiyxOqM8lF5byideaL4G9WyaED6Pjle2bV3KppjKLHkpv9 srFYBK9Q9gBN6xtSEAOc5XL/vCkCAXRidXar91U4= X-Mailman-Approved-At: Fri, 17 Feb 2012 22:09:19 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:59:07 -0000 ... even newer version, seems to have all 'problems' fixed now ;) #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} ) in (*NTFS*) __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" ;; (*FAT*) __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${MNT} __log "${I}:mount (fat)" ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${O} count=3D1 | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) \ ${MNT} || continue done ;; (detach) MOUNT=3D$( mount ) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{pri= nt $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" ;; esac From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 22:41:27 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEA4D1065742 for ; Fri, 17 Feb 2012 22:41:27 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 7732E8FC17 for ; Fri, 17 Feb 2012 22:41:27 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id b9bQ1i0011wpRvQ55AUCFa; Fri, 17 Feb 2012 22:28:12 +0000 Received: from hans3 ([66.30.197.229]) by omta18.westchester.pa.mail.comcast.net with comcast id bAUC1i01v4xSlmi3eAUCdl; Fri, 17 Feb 2012 22:28:12 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyWHj-000J9n-7r; Fri, 17 Feb 2012 17:28:11 -0500 From: Alex Goncharov To: rank1seeker@gmail.com In-reply-to: <20120217.220802.988.2@DOMY-PC> (rank1seeker@gmail.com) References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 17:28:11 -0500 Cc: hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 22:41:27 -0000 ,--- You/rank1seeker@gmail.com (Fri, 17 Feb 2012 23:08:02 +0100) ----* | > For me as a user, that would be a much preferable approach, instilled | > long ago by Linux. I don't like unused stuff around, and I like to | > understand what I am using. | > | > Some build kernel confutation parameters "minimum modules", "medium | > modules", "maximum modules" might be utilized. I would be using | > "medium" or most likely "maximum", leaving me with a minimal kernel. | > | > -- Alex -- alex-goncharov@comcast.net -- | | NO. What does your "NO" stand for? That it would not be a preferable approach "For me as a user"? I wasn't speaking for others :) | > Thinking bigger picture (beyond sound), would it make sense to keep | > GENERIC very minimal, but provide an extensive loader.conf with a | > default install...so most things worked, but were loaded as modules? | > | > Matt | | NO. "NO" here: would not make sense? It will be unlikely done but how do you know what makes sense for others? I for one, don't have any interest in the PCCARD code built into the kernel. Etc. | You can't base a "wish" on a solution for YOURS problems! I was not asking for the new code, but I could express my idea of what made sense for me. | GENERIC must be as giantic as possible, to make as many machines as possible to BOOT and enable all what can be enabled in/on them. | THEN ... individual "strips" unhooked parts -> custom kernel, via | wich you "specialize it", for your hardware! Then provide MINIMAL in sys/ARCH/conf, and one could use it (I am not asking for it -- I've been doing it on my own -- I am talking in principle.) | That is, unless individual is passive/bored (lazy?) and prefer everything on a silver plate ... I don't see any logic in how you passed to this passage. | There are many paths in that case ... | Windows are the easiest solution. THEY THINK FOR YOU! | ;) Ditto. What's bad in "the easiest solution" per se? And one would be not prudent to keep laughing over Windows, thinking Windows NT, when 8 is almost here. But this is off topic, sorry, you all. -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 23:22:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DE571065675; Fri, 17 Feb 2012 23:22:53 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 77BA28FC24; Fri, 17 Feb 2012 23:22:52 +0000 (UTC) Date: Sat, 18 Feb 2012 00:22:50 +0100 From: vermaden To: matt X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EA8F6.6040702@gmail.com> References: <4F3EA8F6.6040702@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329520970; bh=Rq6BOSYujGFJ8d36cubqzTWHDdqUc9jlNJzsPyRAEeU=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=qQS11x1NTDbiTgiUDgXh2XRAtj59iVXJbl+AJ4nEYv5/7uykoW+JBHHSIZwDlPVAx CaEkADmIic4Na8nOVznApAZvTez2pHethx4hqkR31aT7Q3MxMAw4qngviCh2jfb5Dh aj0LvLB2flxOv0ClOjXKkmRBpqHTtmwa+pKy/lYw= X-Mailman-Approved-At: Fri, 17 Feb 2012 23:27:51 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:22:53 -0000 Latest version with additional checks for NTFS and FAT32, to be precise, for NTFS filesystem with label "FAT" and for FAT filesystem with label "NTF= S" ;) #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in (*NTFS*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | head -1 \ | grep -q "NTFS" && { __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" } ;; (*FAT*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | grep -q "FAT32" && { __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${= MNT} __log "${I}:mount (fat)" } ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${I} count=3D1 2> /dev/null | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) \ ${MNT} || continue done ;; (detach) MOUNT=3D$( mount ) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{pri= nt $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" ;; esac From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 17 23:42:12 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C96B71065672 for ; Fri, 17 Feb 2012 23:42:12 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 91E728FC15 for ; Fri, 17 Feb 2012 23:42:12 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so4796109pbc.13 for ; Fri, 17 Feb 2012 15:42:12 -0800 (PST) Received-SPF: pass (google.com: domain of sendtomatt@gmail.com designates 10.68.72.70 as permitted sender) client-ip=10.68.72.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sendtomatt@gmail.com designates 10.68.72.70 as permitted sender) smtp.mail=sendtomatt@gmail.com; dkim=pass header.i=sendtomatt@gmail.com Received: from mr.google.com ([10.68.72.70]) by 10.68.72.70 with SMTP id b6mr36250042pbv.58.1329522132247 (num_hops = 1); Fri, 17 Feb 2012 15:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=7xDdeYf6L+9yaqjtiBIJFf7pp/V1pR1wo+hgruFGuZY=; b=Ca64yjzWToz+juFKvFOb18mj772vwF513BkbG0OCRv/XK6LxnqgQnmc7uSCBwuOj5I 9CutYWiT1UMKOw6MPmlFn9+M8n/HQZiDTZQ942qf0c0ReCmUt9Vqz6dBKaudb2fCK5JQ KJGPmDwIoUZ+4qQjsSj8NbKWW7Xkl5+d7R/fs= Received: by 10.68.72.70 with SMTP id b6mr29143591pbv.58.1329520378477; Fri, 17 Feb 2012 15:12:58 -0800 (PST) Received: from bakeneko.local (adsl-67-118-230-86.dsl.pltn13.pacbell.net. [67.118.230.86]) by mx.google.com with ESMTPS id 7sm17846815pbw.13.2012.02.17.15.12.56 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 15:12:57 -0800 (PST) Message-ID: <4F3EDEBC.7040703@gmail.com> Date: Fri, 17 Feb 2012 15:11:56 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: rank1seeker@gmail.com References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> In-Reply-To: <20120217.220802.988.2@DOMY-PC> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:42:13 -0000 On 02/17/12 14:08, rank1seeker@gmail.com wrote: >> For me as a user, that would be a much preferable approach, instilled >> long ago by Linux. I don't like unused stuff around, and I like to >> understand what I am using. >> >> Some build kernel confutation parameters "minimum modules", "medium >> modules", "maximum modules" might be utilized. I would be using >> "medium" or most likely "maximum", leaving me with a minimal kernel. >> >> -- Alex -- alex-goncharov@comcast.net -- > NO. > >> Thinking bigger picture (beyond sound), would it make sense to keep >> GENERIC very minimal, but provide an extensive loader.conf with a >> default install...so most things worked, but were loaded as modules? >> >> Matt > NO. > > > You can't base a "wish" on a solution for YOURS problems! > > GENERIC must be as giantic as possible, to make as many machines as pos= sible to BOOT and enable all what can be enabled in/on them. > THEN ... individual "strips" unhooked parts -> custom kernel, via wich = you "specialize it", for your hardware! > > That is, unless individual is passive/bored (lazy?) and prefer everythi= ng on a silver plate ... > There are many paths in that case ... > Windows are the easiest solution. THEY THINK FOR YOU! > ;) > > > Domagoj Smol=E8i=E6 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" I'm tired of Linux and "everything should be in the kernel, implemented 4 ways" approach. I think you misunderstood. GENERIC should be able to boot anything bootable within the architecture, right? We agree on that. Is sound required for booting? We have a modular kernel. It makes best-practices-sense to keep the kernel true to what's required to boot and initialize the hardware required to come up multiuser. I am actually against having sound in there at all. However, as a compromise, if it must be in there, then put it in loader.conf and not the kernel. Do we still disagree? Matt From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 00:30:45 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD14F106566B for ; Sat, 18 Feb 2012 00:30:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9218FC08 for ; Sat, 18 Feb 2012 00:30:45 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1I0UhAc028547 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 16:30:44 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3EF18F.5020301@freebsd.org> Date: Fri, 17 Feb 2012 16:32:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: matt References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> In-Reply-To: <4F3EDEBC.7040703@gmail.com> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 8bit Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 00:30:45 -0000 > On 02/17/12 14:08, rank1seeker@gmail.com wrote: >>> For me as a user, that would be a much preferable approach, instilled >>> long ago by Linux. I don't like unused stuff around, and I like to >>> understand what I am using. >>> >>> Some build kernel confutation parameters "minimum modules", "medium >>> modules", "maximum modules" might be utilized. I would be using >>> "medium" or most likely "maximum", leaving me with a minimal kernel. >>> >>> -- Alex -- alex-goncharov@comcast.net -- >> NO. >> >>> Thinking bigger picture (beyond sound), would it make sense to keep >>> GENERIC very minimal, but provide an extensive loader.conf with a >>> default install...so most things worked, but were loaded as modules? >>> >>> Matt >> NO. >> >> >> You can't base a "wish" on a solution for YOURS problems! >> >> GENERIC must be as giantic as possible, to make as many machines as possible to BOOT and enable all what can be enabled in/on them. >> THEN ... individual "strips" unhooked parts -> custom kernel, via wich you "specialize it", for your hardware! >> >> That is, unless individual is passive/bored (lazy?) and prefer everything on a silver plate ... >> There are many paths in that case ... >> Windows are the easiest solution. THEY THINK FOR YOU! >> ;) >> >> >> Domagoj Smolèiæ >> _______________________________________________ >> 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" > I'm tired of Linux and "everything should be in the kernel, implemented > 4 ways" approach. > > I think you misunderstood. GENERIC should be able to boot anything > bootable within the architecture, right? We agree on that. Is sound > required for booting? > > We have a modular kernel. It makes best-practices-sense to keep the > kernel true to what's required to boot and initialize the hardware > required to come up multiuser. I am actually against having sound in > there at all. > > However, as a compromise, if it must be in there, then put it in > loader.conf and not the kernel. > > Do we still disagree? I think we probably should go two ways long and short term 1/ generic is installed at boot a) also install a truely "minimal" kernel and configure modules to use with it. but only once up and running with GENERIC. 2/ in the logn term we should add teh ability to detect devices and load modules needed.. either from the loader, or in early boot. > Matt > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 01:15:01 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CDAAF1065670 for ; Sat, 18 Feb 2012 01:15:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 79086153114; Sat, 18 Feb 2012 01:14:24 +0000 (UTC) Message-ID: <4F3EFB70.5000102@FreeBSD.org> Date: Fri, 17 Feb 2012 17:14:24 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.1) Gecko/20120213 Thunderbird/10.0.1 MIME-Version: 1.0 To: matt References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> In-Reply-To: <4F3EDEBC.7040703@gmail.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 01:15:01 -0000 On 02/17/2012 15:11, matt wrote: > We have a modular kernel. It makes best-practices-sense to keep the > kernel true to what's required to boot and initialize the hardware > required to come up multiuser. I am actually against having sound in > there at all. I think the question is not, "What should be in the kernel?" but rather "What should be on by default?" *How* those things are provided is a different question. One could argue that an intelligent installer combined with a more modular kernel would be the right answer. > However, as a compromise, if it must be in there, then put it in > loader.conf and not the kernel. I keep hoping that if I repeat this enough times that people will get the word. :) Because loading modules through loader.conf is veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called kld that will load the specified modules after disks are mounted. This is at least an order of magnitude faster. Look for kld_list in rc.conf(5) if you want the details, but the short version is that you just do something like, kld_list="umass coretemp ichwd linux nvidia". This is in all the -stable branches (including 7), is already in 9.0, and will be in 8.3. Obviously you have to have everything in kernel and/or loader.conf that's necessary to get your local disks available, and the system to the point where it can start running rc. But everything else can go in kld_list. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 02:37:22 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99FB6106566B for ; Sat, 18 Feb 2012 02:37:22 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 697A68FC14 for ; Sat, 18 Feb 2012 02:37:22 +0000 (UTC) Received: by daec6 with SMTP id c6so4375795dae.13 for ; Fri, 17 Feb 2012 18:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=NNTDmkqc9zKFobtXDs4eqpyDQElqyrvbzl99GQGkG8M=; b=anL0Wf6gisVbANOMJBJM2TNX49/jXlUBgQh0fZG4oRakgAHQ370RXieCxAIhrriBtA CZuGbiPz8yJTy4pQETSrV5H6+aU2V89+4v4Ag6D11Hzs6+D9z4J8u+DdfdynYtEYmzb8 auF2zkIwtobqcJ2y9ETt3/sAk59oECvu+W5ek= Received: by 10.68.216.195 with SMTP id os3mr24161066pbc.137.1329532641976; Fri, 17 Feb 2012 18:37:21 -0800 (PST) Received: from bakeneko.local ([74.195.19.178]) by mx.google.com with ESMTPS id kx17sm18234464pbb.19.2012.02.17.18.37.19 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 18:37:21 -0800 (PST) Message-ID: <4F3F0EA2.7010709@gmail.com> Date: Fri, 17 Feb 2012 18:36:18 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Julian Elischer References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EF18F.5020301@freebsd.org> In-Reply-To: <4F3EF18F.5020301@freebsd.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: quoted-printable Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 02:37:22 -0000 On 02/17/12 16:32, Julian Elischer wrote: >> On 02/17/12 14:08, rank1seeker@gmail.com wrote: >>>> For me as a user, that would be a much preferable approach, instille= d >>>> long ago by Linux. I don't like unused stuff around, and I like to >>>> understand what I am using. >>>> >>>> Some build kernel confutation parameters "minimum modules", "medium >>>> modules", "maximum modules" might be utilized. I would be using >>>> "medium" or most likely "maximum", leaving me with a minimal kernel.= >>>> >>>> -- Alex -- alex-goncharov@comcast.net -- >>> NO. >>> >>>> Thinking bigger picture (beyond sound), would it make sense to keep >>>> GENERIC very minimal, but provide an extensive loader.conf with a >>>> default install...so most things worked, but were loaded as modules?= >>>> >>>> Matt >>> NO. >>> >>> >>> You can't base a "wish" on a solution for YOURS problems! >>> >>> GENERIC must be as giantic as possible, to make as many machines as >>> possible to BOOT and enable all what can be enabled in/on them. >>> THEN ... individual "strips" unhooked parts -> custom kernel, via >>> wich you "specialize it", for your hardware! >>> >>> That is, unless individual is passive/bored (lazy?) and prefer >>> everything on a silver plate ... >>> There are many paths in that case ... >>> Windows are the easiest solution. THEY THINK FOR YOU! >>> ;) >>> >>> >>> Domagoj Smol=E8i=E6 >>> _______________________________________________ >>> 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" >> I'm tired of Linux and "everything should be in the kernel, implemente= d >> 4 ways" approach. >> >> I think you misunderstood. GENERIC should be able to boot anything >> bootable within the architecture, right? We agree on that. Is sound >> required for booting? >> >> We have a modular kernel. It makes best-practices-sense to keep the >> kernel true to what's required to boot and initialize the hardware >> required to come up multiuser. I am actually against having sound in >> there at all. >> >> However, as a compromise, if it must be in there, then put it in >> loader.conf and not the kernel. >> >> Do we still disagree? > > I think we probably should go two ways long and short term > 1/ generic is installed at boot > a) also install a truely "minimal" kernel and configure modules to > use with it. > but only once up and running with GENERIC. > 2/ in the logn term we should add teh ability to detect devices and > load modules > needed.. either from the loader, or in early boot. >> Matt >> >> >> >> _______________________________________________ >> 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" >> >> > I really agree with 2 the most. 1 is true, and subsection a is manual as usual. I can recompile for that. I don't think anything *needs* to be done at all, and this really started on my part with a hypothetical. In the long run, though, option 2 is best. I certainly am not advocating removing tons of stuff from GENERIC, which is what people seem to hear in some cases. I'm advocating the KISS principle (Keep It Simple Stupid) and building a system out from there. Why lock in drivers not necessary to bring up a system? It's more danger (boot hangs, driver bugs, security vulnerabilities) for no benefit. If it's loaded as a module, there is the potential to prevent the load and continue on with boot or bring up the system. Sometimes that counts! Same goes for debugging, troubleshooting, trying to get poorly documented hardware to go through system S3 sleep...etc. Matt From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 03:22:49 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21788106564A for ; Sat, 18 Feb 2012 03:22:49 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E562F8FC16 for ; Sat, 18 Feb 2012 03:22:48 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so4934251pbc.13 for ; Fri, 17 Feb 2012 19:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=xZ7Mgfa3/XsxOqQWcGIKTAeNPQYbps3CmYKVJYvxNLc=; b=i4pdjE57vIUcljflkIO+40LsKQCgY49Wi3gnrmyl0OvHh3vXzD/Qsjz3AeO0TKD34l DMvDHSWLxIDdLaYpK4q676rxgWyT4qAOkfDvBarO4gvQuMu52z4mOCZvroyvvlJ/yJTr XKl+ZadWW6DCUVZV1IiTnLxKMdCy/5cF2p+fE= Received: by 10.68.243.197 with SMTP id xa5mr30151048pbc.68.1329535368637; Fri, 17 Feb 2012 19:22:48 -0800 (PST) Received: from bakeneko.local ([74.195.19.178]) by mx.google.com with ESMTPS id 7sm18334489pbw.13.2012.02.17.19.22.45 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 19:22:46 -0800 (PST) Message-ID: <4F3F1948.1080206@gmail.com> Date: Fri, 17 Feb 2012 19:21:44 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Doug Barton References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> In-Reply-To: <4F3EFB70.5000102@FreeBSD.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 03:22:49 -0000 On 02/17/12 17:14, Doug Barton wrote: > On 02/17/2012 15:11, matt wrote: >> We have a modular kernel. It makes best-practices-sense to keep the >> kernel true to what's required to boot and initialize the hardware >> required to come up multiuser. I am actually against having sound in >> there at all. > I think the question is not, "What should be in the kernel?" but rather= > "What should be on by default?" *How* those things are provided is a > different question. > > One could argue that an intelligent installer combined with a more > modular kernel would be the right answer. > >> However, as a compromise, if it must be in there, then put it in >> loader.conf and not the kernel. > I keep hoping that if I repeat this enough times that people will get > the word. :) Because loading modules through loader.conf is > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called= > kld that will load the specified modules after disks are mounted. This > is at least an order of magnitude faster. Look for kld_list in > rc.conf(5) if you want the details, but the short version is that you > just do something like, kld_list=3D"umass coretemp ichwd linux nvidia".= > This is in all the -stable branches (including 7), is already in 9.0, > and will be in 8.3. > > Obviously you have to have everything in kernel and/or loader.conf > that's necessary to get your local disks available, and the system to > the point where it can start running rc. But everything else can go in > kld_list. > > > hth, > > Doug > Imagine: 1.You've just completed the install 2.Dialog comes up, "Would you like to have FreeBSD detect unloaded drivers and load them at next startup?" YES/NO 3.Reboot 4.If YES: detect unattached drivers like sound, firmware req'd wireless etc, coretemp/amdtemp, smb/iic, wireless?, acpi_ibm/asus/etc and store in kld_list rc variable 5.continue booting 6. If YES: last, one-time RC script. "FreeBSD booted successfully with the autodetected modules. Make changes permanent? YES/NO 7. If YES store kld_list, if NO clear it (or remove additions :) 8. first login In the example, you could just choose NO and manually compile your lean, mean FreeBSD kernel. That would be the power user choice. Choosing YES would be perfect for people just starting FreeBSD for the first time, for machine images intended to be cloned and for live-cd/PXE applications. In other words, you could choose YES and shutdown, capturing the image right before autodetect. If you had driver problems, you could boot single and change the rc.conf kld_list. If there was a security problem with a sound driver, it might not have even been loaded. If there was a suspend issue, etc...kldunload works, and yet the driver may as well be in the kernel. This way you can get GENERIC to be bloated in disk, network, usb, pci, etc drivers needed to boot, and you can use modules for peripherals, sensors, and non-boot essential hardwares. Best of both worlds, I think...well it's a hypothetical, but I look forward to the next round of flames, it's been educational :). Matt From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 03:29:55 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E02F106564A for ; Sat, 18 Feb 2012 03:29:55 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 336078FC0A for ; Sat, 18 Feb 2012 03:29:55 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q1I3TskU039948 for ; Fri, 17 Feb 2012 19:29:54 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4F3F1B31.7070109@rawbw.com> Date: Fri, 17 Feb 2012 19:29:53 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Why /dev/dsp can get into "Device busy" state? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 03:29:55 -0000 At some point, after killing audio playing app with Ctrl-C, I am unable to play sound again with the same app: Can't open audio device /dev/dsp: Device busy But after closing virtual box windows guest, sound is working again. What bothers me, why audio device can even become busy? Isn't it supposed to mix all inputs no matter how many? It usually works fine with many apps playing sound at the same time. What exactly is the condition that causes sound device to become busy? Driver in use is snd_es137x. fstat /dev/dsp doesn't show who opened sound device for some reason. Yuri From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 04:30:38 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BECA0106564A for ; Sat, 18 Feb 2012 04:30:38 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB008FC15 for ; Sat, 18 Feb 2012 04:30:37 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id bGWd1i0051c6gX855GWdRW; Sat, 18 Feb 2012 04:30:37 +0000 Received: from hans3 ([66.30.197.229]) by omta23.westchester.pa.mail.comcast.net with comcast id bGWd1i00C4xSlmi3jGWdh3; Sat, 18 Feb 2012 04:30:37 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RybwR-000JTv-UD; Fri, 17 Feb 2012 23:30:35 -0500 From: Alex Goncharov To: Doug Barton In-reply-to: <4F3EFB70.5000102@FreeBSD.org> (message from Doug Barton on Fri, 17 Feb 2012 17:14:24 -0800) References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> Message-Id: Sender: Alex Goncharov Date: Fri, 17 Feb 2012 23:30:35 -0500 Cc: sendtomatt@gmail.com, rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 04:30:38 -0000 ,--- You/Doug (Fri, 17 Feb 2012 17:14:24 -0800) ----* | I think the question is not, "What should be in the kernel?" but rather | "What should be on by default?" *How* those things are provided is a | different question. | | One could argue that an intelligent installer combined with a more | modular kernel would be the right answer. An intelligent installer: anybody can start coding whatever he wants, but from my perspective this is the last thing that FreeBSD is in need of. The old installer that brought me to FreeBSD in the year 2004, was doing its job all right and I liked it more than the "more intelligent" installers I had used with other OSes. Once you learned it, it was straightforward and efficient. With deficiencies, but nothing that could not be resolved by rebooting the system. "Once you learned" is key -- FreeBSD is the environment you want to learn, it's pleasant to learn, and this is a significant part of its attraction. Keep learning and soon "you" won't need an intelligent installer. In short time, "you" may not need any installer at all. Modular kernel: again, to a large extent, this is more about learning and comprehending the OS than about the sizes and bootup times. What I saw in FreeBSD 7 and 8, about the kernel and modules, was transparent and logical: the basic devices would be a part of the 'kernel', and the nice-to-haves, e.g. for the sound, would be optionally loaded (e.g. through loader.conf). What I see in 9 now is very confusing for me; e.g.: * Why 'snd_hda.ko' even exists, if the whole 'snd_hda' implementation lives in 'kernel' now? If not the whole, why is it split between 'kernel' and 'snd_hda.ko'? * Why did 'snd' earn the honor to live in 'kernel', but 'linux.ko' did not? I can live without sound, but if the Linux compatibility were not available, I suspect that all my systems would lose FreeBSD immediately. Not to have a well working Flash plugins is unacceptable (for me) today. So, why do I have to say 'linux_enable="YES"' in rc.conf and load linux.ko to get this functionality, while all this stuff comes in the 'kernel', kldstat -v | grep snd_ 253 pci/snd_hda 252 hdac/snd_hda_pcm 251 pci/snd_via8233 250 pci/snd_ich 249 pci/snd_es137x -- with a variety of cards. All of them, you will hardly find at the same time on any machine. * And what about CAM? kldstat | grep cam 2 1 0xffffffff81467000 5570 atapicam.ko Is having a working CD less or more important than a potential for five types of a sound card? Compare: ---------------------------------------- uname -sr; grep -i cam /usr/src/sys/amd64/conf/GENERIC FreeBSD 8.2-STABLE device aacp # SCSI passthrough for aac (requires CAM) ---------- uname -sr; grep -i cam /usr/src/sys/amd64/conf/GENERIC FreeBSD 9.0-STABLE options ATA_CAM # Handle legacy controllers with CAM device ctl # CAM Target Layer device aacp # SCSI passthrough for aac (requires CAM) ---------------------------------------- Should I now (in 9) have: ---------------------------------------- grep -i cam /boot/loader.conf => atapicam_load="YES" ---------------------------------------- as I had in 8, or it's no longer necessary because of the above extract from /usr/src/sys/amd64/conf/GENERIC? I really don't know -- please tell me somebody. I can, of course, comment out the 'atapicam_load="YES"' line in loader.conf, reboot and see what happens, but I'd prefer to understand it without or before the experimentation. | I keep hoping that if I repeat this enough times that people will get | the word. :) Because loading modules through loader.conf is | veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called | kld that will load the specified modules after disks are mounted. This | is at least an order of magnitude faster. Look for kld_list in | rc.conf(5) if you want the details, but the short version is that you | just do something like, kld_list="umass coretemp ichwd linux nvidia". | This is in all the -stable branches (including 7), is already in 9.0, | and will be in 8.3. I will use this -- thank you! But again: should 'atapicam' be in 'kld_list' (or loader.conf), now that I see new CAM things in GENERIC? | Obviously you have to have everything in kernel and/or loader.conf | that's necessary to get your local disks available, and the system to | the point where it can start running rc. But everything else can go in | kld_list. Right, and one has a flexible control over the modules, resulting in easier tuning and experimentation. -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 11:52:36 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577F71065670; Sat, 18 Feb 2012 11:52:36 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 306318FC19; Sat, 18 Feb 2012 11:52:36 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q1IBqZ03050779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Feb 2012 03:52:35 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q1IBqZ64050778; Sat, 18 Feb 2012 03:52:35 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA04391; Sat, 18 Feb 12 03:44:39 PST Date: Sat, 18 Feb 2012 10:43:29 -0800 From: perryh@pluto.rain.com To: dougb@freebsd.org Message-Id: <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> In-Reply-To: <4F3EFB70.5000102@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rank1seeker@gmail.com, sendtomatt@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 11:52:36 -0000 Doug Barton wrote: > loading modules through loader.conf is > veeeeeerrrrryyyyyy sssssllllloooooowwwwww ... Is it noticeably slower to load (say) a 6MB kernel + 2MB of modules than to load an 8MB kernel? If so, any idea why? From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 09:48:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E2E1106566C; Sat, 18 Feb 2012 09:48:13 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id A2D458FC08; Sat, 18 Feb 2012 09:48:12 +0000 (UTC) Date: Sat, 18 Feb 2012 10:48:11 +0100 From: vermaden To: matt X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EE186.4020801@gmail.com> References: <4F3EA8F6.6040702@gmail.com> <4F3EE186.4020801@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329558491; bh=sKfXBtqP9LdO6CuRPV5e5Ua4y5ZYmcz6EfXzdGSTKuw=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=e6pI6h6g0szgcJb+xNL8Q2b6JgQxK7eZNNygrz+LHa2imaGrd/xc8UWDh7gCe7DXK S+ER3am4a+hOvmVt/BdCbJv2WJI7hl2jZ4Qt7qtczSjsmzLovLIuplYQSvu/lGmTjT /Y2a3P5ZuS7pswlnRXMM0IC+6GUHLdudaoqvTDYQ= X-Mailman-Approved-At: Sat, 18 Feb 2012 12:15:24 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 09:48:13 -0000 Added a check if ntfs-3g is available, if not then mount_ntfs is used inste= ad. Added deleting of empty directories at ${MNTPREFIX}. Added ${MNTPREFIX} to be set to /mnt or /media according to preference #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin MNTPREFIX=3D"/media" LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"${MNTPREFIX}/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in (*NTFS*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | head -1 \ | grep -q "NTFS" && { __create_mount_point ${I} which ntfs-3g 1> /dev/null 2> /dev/null && { ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ } || { mount_ntfs ${I} ${MNT} } __log "${I}:mount (ntfs)" } ;; (*FAT*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | grep -q "FAT32" && { __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${= MNT} __log "${I}:mount (fat)" } ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${I} count=3D1 2> /dev/null | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) \ ${MNT} || continue done ;; (detach) MOUNT=3D$( mount ) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{pri= nt $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" find ${MNTPREFIX} -type d -empty -delete ;; esac > Not sure if you've looked at disktype in sysutils > but it may be useful to you. I will get look into that, thanks ;) > Neat scripts! > Matt Thanks mate. Regards, vermaden --=20 ... From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 13:10:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8423106566B; Sat, 18 Feb 2012 13:10:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id E07B58FC08; Sat, 18 Feb 2012 13:10:58 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.208.111] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 243331715; Sat, 18 Feb 2012 14:10:56 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Sat, 18 Feb 2012 14:09:08 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <4F3EE186.4020801@gmail.com> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202181409.08859.hselasky@c2i.net> Cc: matt , vermaden , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 13:11:00 -0000 On Saturday 18 February 2012 10:48:11 vermaden wrote: > Added a check if ntfs-3g is available, if not then mount_ntfs is used > instead. Added deleting of empty directories at ${MNTPREFIX}. > Added ${MNTPREFIX} to be set to /mnt or /media according to preference > > #! /bin/sh > > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin > MNTPREFIX="/media" > LOG="/var/log/automount.log" > STATE="/var/run/automount.state" > DATEFMT="%Y-%m-%d %H:%M:%S" > > __create_mount_point() { # /* 1=DEV */ > MNT="${MNTPREFIX}/$( basename ${1} )" > mkdir -p ${MNT} > } > > __state_lock() { > while [ -f ${STATE}.lock ]; do sleep 0.5; done > > :> ${STATE}.lock > > } > > __state_unlock() { > rm ${STATE}.lock > } > > __state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */ > __state_lock > grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { > __log "${1}:duplicated '${STATE}'" > return 1 > } > echo "${1} ${2} ${3}" >> ${STATE} > __state_unlock > } > > __state_remove() { # /* 1=MNT 2=STATE 3=LINE */ > BSMNT=$( echo ${1} | sed 's/\//\\\//g' ) > sed -i '' "/${BSMNT}\$/d" ${2} > } > > __log() { # /* @=MESSAGE */ > echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} > } > > case ${2} in > (attach) > for I in /dev/${1}* > do > case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in > (*NTFS*) > dd < ${I} count=1 2> /dev/null \ > > | strings \ > | head -1 \ > | grep -q "NTFS" && { > > __create_mount_point ${I} > which ntfs-3g 1> /dev/null 2> /dev/null && { > ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ > } || { > mount_ntfs ${I} ${MNT} > } > __log "${I}:mount (ntfs)" > } > ;; > (*FAT*) > dd < ${I} count=1 2> /dev/null \ > > | strings \ > | grep -q "FAT32" && { > > __create_mount_point ${I} > fsck_msdosfs -y ${I} > mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} > ${MNT} __log "${I}:mount (fat)" > } > ;; > (*ext2*) > __create_mount_point ${I} > fsck.ext2 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext2)" > ;; > (*ext3*) > __create_mount_point ${I} > fsck.ext3 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext3)" > ;; > (*ext4*) > __create_mount_point ${I} > fsck.ext4 -y ${I} > ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ > __log "${I}:mount (ext4)" > ;; > (*Unix\ Fast\ File*) > __create_mount_point ${I} > fsck_ufs -y ${I} > mount ${I} ${MNT} > __log "${I}:mount (ufs)" > ;; > (*) > case $( dd < ${I} count=1 2> /dev/null | strings | head -1 ) in > (EXFAT) > __create_mount_point ${I} > mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ > __log "${I}:mount (ufs)" > ;; > (*) continue ;; > esac > ;; > esac > __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' > ) \ ${MNT} || continue > done > ;; > > (detach) > MOUNT=$( mount ) > __state_lock > grep ${1} ${STATE} \ > > | while read DEV PROVIDER MNT > > do > TARGET=$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{print > $3}' ) [ -z ${TARGET} ] && { > __state_remove ${MNT} ${STATE} ${LINE} > continue > } > umount -f ${TARGET} & > unset TARGET > __state_remove ${MNT} ${STATE} ${LINE} > __log "${DEV}:umount" > done > __state_unlock > __log "/dev/${1}:detach" > find ${MNTPREFIX} -type d -empty -delete > ;; > > esac > > > Not sure if you've looked at disktype in sysutils > > but it may be useful to you. > Hi, Should your script be written like an rc.d script, so that one can enable/disable this automounting from /etc/rc.conf? --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 17:08:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6601065672 for ; Sat, 18 Feb 2012 17:08:20 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 74DC28FC08 for ; Sat, 18 Feb 2012 17:08:18 +0000 (UTC) Received: (qmail 27891 invoked by uid 1004); 18 Feb 2012 17:08:42 -0000 Message-ID: <4F3FDA8F.7080807@uffe.org> Date: Sat, 18 Feb 2012 18:06:23 +0100 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> In-Reply-To: <201202181409.08859.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vermaden Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 17:08:20 -0000 On 2012-02-18 14:09, Hans Petter Selasky wrote: > On Saturday 18 February 2012 10:48:11 vermaden wrote: >> Added a check if ntfs-3g is available, if not then mount_ntfs is used >> instead. Added deleting of empty directories at ${MNTPREFIX}. >> Added ${MNTPREFIX} to be set to /mnt or /media according to preference >> >> #! /bin/sh >> >> PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin >> MNTPREFIX="/media" >> LOG="/var/log/automount.log" >> STATE="/var/run/automount.state" >> DATEFMT="%Y-%m-%d %H:%M:%S" >> >> __create_mount_point() { # /* 1=DEV */ >> MNT="${MNTPREFIX}/$( basename ${1} )" >> mkdir -p ${MNT} >> } >> >> __state_lock() { >> while [ -f ${STATE}.lock ]; do sleep 0.5; done >> >> :> ${STATE}.lock >> >> } >> >> __state_unlock() { >> rm ${STATE}.lock >> } >> >> __state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */ >> __state_lock >> grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null&& { >> __log "${1}:duplicated '${STATE}'" >> return 1 >> } >> echo "${1} ${2} ${3}">> ${STATE} >> __state_unlock >> } >> >> __state_remove() { # /* 1=MNT 2=STATE 3=LINE */ >> BSMNT=$( echo ${1} | sed 's/\//\\\//g' ) >> sed -i '' "/${BSMNT}\$/d" ${2} >> } >> >> __log() { # /* @=MESSAGE */ >> echo $( date +"${DATEFMT}" ) ${@}>> ${LOG} >> } >> >> case ${2} in >> (attach) >> for I in /dev/${1}* >> do >> case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in >> (*NTFS*) >> dd< ${I} count=1 2> /dev/null \ >> >> | strings \ >> | head -1 \ >> | grep -q "NTFS"&& { >> >> __create_mount_point ${I} >> which ntfs-3g 1> /dev/null 2> /dev/null&& { >> ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ >> } || { >> mount_ntfs ${I} ${MNT} >> } >> __log "${I}:mount (ntfs)" >> } >> ;; >> (*FAT*) >> dd< ${I} count=1 2> /dev/null \ >> >> | strings \ >> | grep -q "FAT32"&& { >> >> __create_mount_point ${I} >> fsck_msdosfs -y ${I} >> mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} >> ${MNT} __log "${I}:mount (fat)" >> } >> ;; >> (*ext2*) >> __create_mount_point ${I} >> fsck.ext2 -y ${I} >> mount -t ext2fs ${I} ${MNT} >> __log "${I}:mount (ext2)" >> ;; >> (*ext3*) >> __create_mount_point ${I} >> fsck.ext3 -y ${I} >> mount -t ext2fs ${I} ${MNT} >> __log "${I}:mount (ext3)" >> ;; >> (*ext4*) >> __create_mount_point ${I} >> fsck.ext4 -y ${I} >> ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ >> __log "${I}:mount (ext4)" >> ;; >> (*Unix\ Fast\ File*) >> __create_mount_point ${I} >> fsck_ufs -y ${I} >> mount ${I} ${MNT} >> __log "${I}:mount (ufs)" >> ;; >> (*) >> case $( dd< ${I} count=1 2> /dev/null | strings | head -1 ) in >> (EXFAT) >> __create_mount_point ${I} >> mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ >> __log "${I}:mount (ufs)" >> ;; >> (*) continue ;; >> esac >> ;; >> esac >> __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' >> ) \ ${MNT} || continue >> done >> ;; >> >> (detach) >> MOUNT=$( mount ) >> __state_lock >> grep ${1} ${STATE} \ >> >> | while read DEV PROVIDER MNT >> >> do >> TARGET=$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{print >> $3}' ) [ -z ${TARGET} ]&& { >> __state_remove ${MNT} ${STATE} ${LINE} >> continue >> } >> umount -f ${TARGET}& >> unset TARGET >> __state_remove ${MNT} ${STATE} ${LINE} >> __log "${DEV}:umount" >> done >> __state_unlock >> __log "/dev/${1}:detach" >> find ${MNTPREFIX} -type d -empty -delete >> ;; >> >> esac >> >>> Not sure if you've looked at disktype in sysutils >>> but it may be useful to you. >> > > Hi, > > Should your script be written like an rc.d script, so that one can > enable/disable this automounting from /etc/rc.conf? > Nice, Some comments: Instead of requiring modification to /etc/devd.conf why not just put a "plugin" conf-file in /etc/devd/ - well even better put in /usr/local/etc/devd/ - that way your devd.conf modifications are not lost upon patching/updating base os. There is an existing port called "automounter" by Dominic Fandrey which is much similar to your work. You can get inspired of how he places his devd.conf in /usr/local/etc/devd/ His "automounter" also works with disk labels (as found in /dev/ufs/ and /dev/msdosfs/ etc) You should consider make a port out of your work. /Uffe From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 17:28:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7044106566B; Sat, 18 Feb 2012 17:28:13 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 26DEA8FC13; Sat, 18 Feb 2012 17:28:12 +0000 (UTC) Received: by lagz14 with SMTP id z14so7242037lag.13 for ; Sat, 18 Feb 2012 09:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PBKAlx46k2x4ueJrx2YXOdyrCBp8k5B/D0Kgf+gCcpE=; b=jCOyAqzwSU32DdZWGZFC+IYGnd5Cfa36GblJeBLI9P/4gErotEK0+/W1U/kZGRxdnu LfuyV0hbTaeZLlD0drdF0XBDqTIqUyGp8wgDBNRulJoqhVyPXAcrtAg8xjLksFqny+z3 4y+Lk0mUwq11RT3HYe8da0ej+YICTkiwDGzCA= Received: by 10.152.130.102 with SMTP id od6mr8395303lab.14.1329584201455; Sat, 18 Feb 2012 08:56:41 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id j4sm16417332lbf.6.2012.02.18.08.56.39 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 08:56:40 -0800 (PST) Date: Sat, 18 Feb 2012 18:56:51 +0200 From: Gleb Kurtsou To: vermaden Message-ID: <20120218165650.GA3552@reks> References: <4F3EA8F6.6040702@gmail.com> <4F3EE186.4020801@gmail.com> 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) Cc: matt , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 17:28:13 -0000 On (18/02/2012 10:48), vermaden wrote: > Added a check if ntfs-3g is available, if not then mount_ntfs is used instead. > Added deleting of empty directories at ${MNTPREFIX}. > Added ${MNTPREFIX} to be set to /mnt or /media according to preference > > #! /bin/sh > > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin > MNTPREFIX="/media" > LOG="/var/log/automount.log" > STATE="/var/run/automount.state" > DATEFMT="%Y-%m-%d %H:%M:%S" > > __create_mount_point() { # /* 1=DEV */ > MNT="${MNTPREFIX}/$( basename ${1} )" > mkdir -p ${MNT} > } > > __state_lock() { > while [ -f ${STATE}.lock ]; do sleep 0.5; done > :> ${STATE}.lock > } Why not keep it stateless, unmounting by hand would kill integrity. Usage of `file` is a big security concern. I think geom config and list of mounted file systems should be sufficient for collecting information at runtime. Although it may not be that easy for disks without partitioning. I'm using a python script for mounting/unmounting removable disks, but having similar tool written in sh would be great. https://github.com/glk/mmount Thanks, Gleb. > > __state_unlock() { > rm ${STATE}.lock > } > > __state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */ > __state_lock > grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { > __log "${1}:duplicated '${STATE}'" > return 1 > } > echo "${1} ${2} ${3}" >> ${STATE} > __state_unlock > } > > __state_remove() { # /* 1=MNT 2=STATE 3=LINE */ > BSMNT=$( echo ${1} | sed 's/\//\\\//g' ) > sed -i '' "/${BSMNT}\$/d" ${2} > } > > __log() { # /* @=MESSAGE */ > echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} > } > > case ${2} in > (attach) > for I in /dev/${1}* > do > case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in > (*NTFS*) > dd < ${I} count=1 2> /dev/null \ > | strings \ > | head -1 \ > | grep -q "NTFS" && { > __create_mount_point ${I} > which ntfs-3g 1> /dev/null 2> /dev/null && { > ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ > } || { > mount_ntfs ${I} ${MNT} > } > __log "${I}:mount (ntfs)" > } > ;; > (*FAT*) > dd < ${I} count=1 2> /dev/null \ > | strings \ > | grep -q "FAT32" && { > __create_mount_point ${I} > fsck_msdosfs -y ${I} > mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${MNT} > __log "${I}:mount (fat)" > } > ;; > (*ext2*) > __create_mount_point ${I} > fsck.ext2 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext2)" > ;; > (*ext3*) > __create_mount_point ${I} > fsck.ext3 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext3)" > ;; > (*ext4*) > __create_mount_point ${I} > fsck.ext4 -y ${I} > ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ > __log "${I}:mount (ext4)" > ;; > (*Unix\ Fast\ File*) > __create_mount_point ${I} > fsck_ufs -y ${I} > mount ${I} ${MNT} > __log "${I}:mount (ufs)" > ;; > (*) > case $( dd < ${I} count=1 2> /dev/null | strings | head -1 ) in > (EXFAT) > __create_mount_point ${I} > mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ > __log "${I}:mount (ufs)" > ;; > (*) continue ;; > esac > ;; > esac > __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' ) \ > ${MNT} || continue > done > ;; > > (detach) > MOUNT=$( mount ) > __state_lock > grep ${1} ${STATE} \ > | while read DEV PROVIDER MNT > do > TARGET=$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{print $3}' ) > [ -z ${TARGET} ] && { > __state_remove ${MNT} ${STATE} ${LINE} > continue > } > umount -f ${TARGET} & > unset TARGET > __state_remove ${MNT} ${STATE} ${LINE} > __log "${DEV}:umount" > done > __state_unlock > __log "/dev/${1}:detach" > find ${MNTPREFIX} -type d -empty -delete > ;; > > esac > > > > > Not sure if you've looked at disktype in sysutils > > but it may be useful to you. > > I will get look into that, thanks ;) > > > > > Neat scripts! > > Matt > > Thanks mate. > > > > Regards, > vermaden From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 19:06:26 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 040ED1065672; Sat, 18 Feb 2012 19:06:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CD7548FC17; Sat, 18 Feb 2012 19:06:24 +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 VAA20246; Sat, 18 Feb 2012 21:06:23 +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 1Rypbz-000CZG-Ad; Sat, 18 Feb 2012 21:06:23 +0200 Message-ID: <4F3FF690.5050600@FreeBSD.org> Date: Sat, 18 Feb 2012 21:05:52 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120215 Thunderbird/10.0.1 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: callouts precision X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 19:06:26 -0000 Just want to double-check myself. It seems that currently, thanks to event timers, we mostly should be able to schedule a hardware timer to fire at almost arbitrary moment with very fine precision. OTOH, our callout subsystem still seems to be completely tick oriented in the sense that all timeouts are specified and kept in ticks. As a result, it's impossible to use e.g. nanosleep(2) with a precision better than HZ. How deeply ticks are ingrained into callout(9)? Are they used only as a measure of time? Or are there any dependencies on them being integers, like for indexing, etc? In other words, how hard it would be to replace ticks with e.g. bintime as an internal representation of time in callout(9) [leaving interfaces alone for the start]? Is it easier to retrofit that code or to replace it with something new? Thank you. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 19:21:06 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82949106566C for ; Sat, 18 Feb 2012 19:21:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 06A438FC0C for ; Sat, 18 Feb 2012 19:21:05 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3412255wib.13 for ; Sat, 18 Feb 2012 11:21:05 -0800 (PST) Received-SPF: pass (google.com: domain of adrian.chadd@gmail.com designates 10.180.93.4 as permitted sender) client-ip=10.180.93.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adrian.chadd@gmail.com designates 10.180.93.4 as permitted sender) smtp.mail=adrian.chadd@gmail.com; dkim=pass header.i=adrian.chadd@gmail.com Received: from mr.google.com ([10.180.93.4]) by 10.180.93.4 with SMTP id cq4mr5474112wib.21.1329592865049 (num_hops = 1); Sat, 18 Feb 2012 11:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Eav5rtJQrCsADmGo+ySQ741xjQo4qnv/+8gZMq7QoGM=; b=ATP4rhreodZsnXo3KLtmqjSKNBbMxEcIxzC7XRofhbEuGj13uK0dOg4tDxbb1HRkCt VBFt+iEEVUTocBRXGTBb7FUGWrggHzfreCVi7Wv5qzWfGV4Mgs5pRUEYATit7O+4vbaA JqmcQntwXi+kPvfoWb78Umr/fAjF+lhx4P/Ek= MIME-Version: 1.0 Received: by 10.180.93.4 with SMTP id cq4mr4500675wib.21.1329591498974; Sat, 18 Feb 2012 10:58:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Sat, 18 Feb 2012 10:58:18 -0800 (PST) In-Reply-To: <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> <4f3ff151.FznGzC6RC0a5qBKx%perryh@pluto.rain.com> Date: Sat, 18 Feb 2012 10:58:18 -0800 X-Google-Sender-Auth: xfgTqTmOg4vxm5nJQNYPZwGaMug Message-ID: From: Adrian Chadd To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Cc: rank1seeker@gmail.com, sendtomatt@gmail.com, dougb@freebsd.org, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 19:21:06 -0000 Very very inefficient BIOS and loader behaviour? I'm not sure libufs is caching anything? Adrian From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 19:43:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76BAE106566B; Sat, 18 Feb 2012 19:43:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id CEB328FC0A; Sat, 18 Feb 2012 19:43:11 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3421988wib.13 for ; Sat, 18 Feb 2012 11:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OSX+641liIhz1BRl1EzM2VDcoWJlJwGwBvSA9foaTFc=; b=JH7hKZU1D6OSpQqrLQVuf+0JlIm3I2QPtGL2vDCC4X0gScbR6ja+anuWD28g1GeC/T o+566UCFYQZKi4L89wQmc0Um9xovQIrX8SxCvhwXE/2q5ZQ3nMFxybxerOpuN4P33UTB GKQ+GAHWe9XX66lPhjDvhajXwqQwUd+9spamM= Received: by 10.180.83.97 with SMTP id p1mr4663161wiy.19.1329594190748; Sat, 18 Feb 2012 11:43:10 -0800 (PST) Received: from mavbook.mavhome.dp.ua (95-109-198-194.dialup.umc.net.ua. [95.109.198.194]) by mx.google.com with ESMTPS id m16sm13175709wie.9.2012.02.18.11.43.04 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 11:43:09 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3FFF33.2050700@FreeBSD.org> Date: Sat, 18 Feb 2012 21:42:43 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Andriy Gapon References: <4F3FF690.5050600@FreeBSD.org> In-Reply-To: <4F3FF690.5050600@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: callouts precision X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 19:43:12 -0000 On 18.02.2012 21:05, Andriy Gapon wrote: > Just want to double-check myself. > It seems that currently, thanks to event timers, we mostly should be able to > schedule a hardware timer to fire at almost arbitrary moment with very fine > precision. > OTOH, our callout subsystem still seems to be completely tick oriented in the > sense that all timeouts are specified and kept in ticks. > As a result, it's impossible to use e.g. nanosleep(2) with a precision better > than HZ. > > How deeply ticks are ingrained into callout(9)? Are they used only as a measure > of time? Or are there any dependencies on them being integers, like for > indexing, etc? > In other words, how hard it would be to replace ticks with e.g. bintime as an > internal representation of time in callout(9) [leaving interfaces alone for the > start]? Is it easier to retrofit that code or to replace it with something new? Pending callouts are now stored in large array of unsorted lists, where last bits of callout time is the array index. It is quite effective for insert/delete operation. It is ineffective for getting next event time needed for new event timers, but it is rare operation. Using arbitrary time values in that case is very problematic. It would require complete internal redesign. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 20:20:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 807A61065674 for ; Sat, 18 Feb 2012 20:20:57 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id D55078FC22 for ; Sat, 18 Feb 2012 20:20:56 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 70F446A6648; Sat, 18 Feb 2012 21:20:55 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id fN9cuwnWfKWo; Sat, 18 Feb 2012 21:20:55 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 1DEDB6A6647; Sat, 18 Feb 2012 21:20:55 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id q1IKKshJ078834; Sat, 18 Feb 2012 21:20:54 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id q1IKKsaD078550; Sat, 18 Feb 2012 21:20:54 +0100 (CET) (envelope-from lars) Date: Sat, 18 Feb 2012 21:20:54 +0100 From: Lars Engels To: Uffe Jakobsen Message-ID: <20120218202054.GK14469@e-new.0x20.net> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <4F3FDA8F.7080807@uffe.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ah40dssYA/cDqAW1" Content-Disposition: inline In-Reply-To: <4F3FDA8F.7080807@uffe.org> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 18 Feb 2012 20:26:59 +0000 Cc: freebsd-hackers@freebsd.org, vermaden Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 20:20:57 -0000 --Ah40dssYA/cDqAW1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 18, 2012 at 06:06:23PM +0100, Uffe Jakobsen wrote: >=20 >=20 > On 2012-02-18 14:09, Hans Petter Selasky wrote: > > On Saturday 18 February 2012 10:48:11 vermaden wrote: > >> Added a check if ntfs-3g is available, if not then mount_ntfs is used > >> instead. Added deleting of empty directories at ${MNTPREFIX}. > >> Added ${MNTPREFIX} to be set to /mnt or /media according to preference > >> > >> #! /bin/sh > >> > >> PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin > >> MNTPREFIX=3D"/media" > >> LOG=3D"/var/log/automount.log" > >> STATE=3D"/var/run/automount.state" > >> DATEFMT=3D"%Y-%m-%d %H:%M:%S" > >> > >> __create_mount_point() { # /* 1=3DDEV */ > >> MNT=3D"${MNTPREFIX}/$( basename ${1} )" > >> mkdir -p ${MNT} > >> } > >> > >> __state_lock() { > >> while [ -f ${STATE}.lock ]; do sleep 0.5; done > >> > >> :> ${STATE}.lock > >> > >> } > >> > >> __state_unlock() { > >> rm ${STATE}.lock > >> } > >> > >> __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ > >> __state_lock > >> grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null&& { > >> __log "${1}:duplicated '${STATE}'" > >> return 1 > >> } > >> echo "${1} ${2} ${3}">> ${STATE} > >> __state_unlock > >> } > >> > >> __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ > >> BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) > >> sed -i '' "/${BSMNT}\$/d" ${2} > >> } > >> > >> __log() { # /* @=3DMESSAGE */ > >> echo $( date +"${DATEFMT}" ) ${@}>> ${LOG} > >> } > >> > >> case ${2} in > >> (attach) > >> for I in /dev/${1}* > >> do > >> case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in > >> (*NTFS*) > >> dd< ${I} count=3D1 2> /dev/null \ > >> > >> | strings \ > >> | head -1 \ > >> | grep -q "NTFS"&& { > >> > >> __create_mount_point ${I} > >> which ntfs-3g 1> /dev/null 2> /dev/null&& { > >> ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ > >> } || { > >> mount_ntfs ${I} ${MNT} > >> } > >> __log "${I}:mount (ntfs)" > >> } > >> ;; > >> (*FAT*) > >> dd< ${I} count=3D1 2> /dev/null \ > >> > >> | strings \ > >> | grep -q "FAT32"&& { > >> > >> __create_mount_point ${I} > >> fsck_msdosfs -y ${I} > >> mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 $= {I} > >> ${MNT} __log "${I}:mount (fat)" > >> } > >> ;; > >> (*ext2*) > >> __create_mount_point ${I} > >> fsck.ext2 -y ${I} > >> mount -t ext2fs ${I} ${MNT} > >> __log "${I}:mount (ext2)" > >> ;; > >> (*ext3*) > >> __create_mount_point ${I} > >> fsck.ext3 -y ${I} > >> mount -t ext2fs ${I} ${MNT} > >> __log "${I}:mount (ext3)" > >> ;; > >> (*ext4*) > >> __create_mount_point ${I} > >> fsck.ext4 -y ${I} > >> ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ > >> __log "${I}:mount (ext4)" > >> ;; > >> (*Unix\ Fast\ File*) > >> __create_mount_point ${I} > >> fsck_ufs -y ${I} > >> mount ${I} ${MNT} > >> __log "${I}:mount (ufs)" > >> ;; > >> (*) > >> case $( dd< ${I} count=3D1 2> /dev/null | strings | head = -1 ) in > >> (EXFAT) > >> __create_mount_point ${I} > >> mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ > >> __log "${I}:mount (ufs)" > >> ;; > >> (*) continue ;; > >> esac > >> ;; > >> esac > >> __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf= $1}' > >> ) \ ${MNT} || continue > >> done > >> ;; > >> > >> (detach) > >> MOUNT=3D$( mount ) > >> __state_lock > >> grep ${1} ${STATE} \ > >> > >> | while read DEV PROVIDER MNT > >> > >> do > >> TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk= '{print > >> $3}' ) [ -z ${TARGET} ]&& { > >> __state_remove ${MNT} ${STATE} ${LINE} > >> continue > >> } > >> umount -f ${TARGET}& > >> unset TARGET > >> __state_remove ${MNT} ${STATE} ${LINE} > >> __log "${DEV}:umount" > >> done > >> __state_unlock > >> __log "/dev/${1}:detach" > >> find ${MNTPREFIX} -type d -empty -delete > >> ;; > >> > >> esac > >> > >>> Not sure if you've looked at disktype in sysutils > >>> but it may be useful to you. > >> > > > > Hi, > > > > Should your script be written like an rc.d script, so that one can > > enable/disable this automounting from /etc/rc.conf? > > >=20 > Nice, >=20 > Some comments: >=20 > Instead of requiring modification to /etc/devd.conf why not just put a=20 > "plugin" conf-file in /etc/devd/ - well even better put in=20 > /usr/local/etc/devd/ - that way your devd.conf modifications are not=20 > lost upon patching/updating base os. >=20 > There is an existing port called "automounter" by Dominic Fandrey which= =20 > is much similar to your work. >=20 > You can get inspired of how he places his devd.conf in /usr/local/etc/dev= d/ > His "automounter" also works with disk labels (as found in /dev/ufs/ and= =20 > /dev/msdosfs/ etc) >=20 > You should consider make a port out of your work. And please don't hardcode polish locales in mount_msdosfs :-) --Ah40dssYA/cDqAW1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9ACCYACgkQKc512sD3afiYdgCfVrqmbXw8NMRQfdq4BvDQtGbd EE8An1oxGxkJHj9kBj1SEq/IAF7wKPY5 =rfsh -----END PGP SIGNATURE----- --Ah40dssYA/cDqAW1-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 20:41:07 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61101106566C; Sat, 18 Feb 2012 20:41:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 748728FC0C; Sat, 18 Feb 2012 20:41:06 +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 WAA20902; Sat, 18 Feb 2012 22:41:04 +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 1Ryr5c-000Cbk-G3; Sat, 18 Feb 2012 22:41:04 +0200 Message-ID: <4F400CC1.8030504@FreeBSD.org> Date: Sat, 18 Feb 2012 22:40:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120215 Thunderbird/10.0.1 MIME-Version: 1.0 To: Alexander Motin , freebsd-hackers@FreeBSD.org References: <4F3FF690.5050600@FreeBSD.org> <4F3FFF33.2050700@FreeBSD.org> In-Reply-To: <4F3FFF33.2050700@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Re: callouts precision X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 20:41:07 -0000 on 18/02/2012 21:42 Alexander Motin said the following: > On 18.02.2012 21:05, Andriy Gapon wrote: >> Just want to double-check myself. >> It seems that currently, thanks to event timers, we mostly should be able to >> schedule a hardware timer to fire at almost arbitrary moment with very fine >> precision. >> OTOH, our callout subsystem still seems to be completely tick oriented in the >> sense that all timeouts are specified and kept in ticks. >> As a result, it's impossible to use e.g. nanosleep(2) with a precision better >> than HZ. >> >> How deeply ticks are ingrained into callout(9)? Are they used only as a measure >> of time? Or are there any dependencies on them being integers, like for >> indexing, etc? >> In other words, how hard it would be to replace ticks with e.g. bintime as an >> internal representation of time in callout(9) [leaving interfaces alone for the >> start]? Is it easier to retrofit that code or to replace it with something new? > > Pending callouts are now stored in large array of unsorted lists, where last > bits of callout time is the array index. It is quite effective for insert/delete > operation. It is ineffective for getting next event time needed for new event > timers, but it is rare operation. Using arbitrary time values in that case is > very problematic. It would require complete internal redesign. > I see. Thank you for the insight! One possible hack that I can think of is to use "pseudo-ticks" in the callout implementation instead of real ticks. E.g. such a pseudo-tick could be set equal to 1 microsecond instead of 1/hz (it could be tunable). Then, of course, instead of driving the callouts via hardclock/softclock, they would have to be driven directly from event timers. And they would have to use current microseconds uptime instead of ticks, obviously. This would also require a revision of types used to store timeout values. Current 'int' would not be adequate anymore, it seems. It looks like Timer_Wheel_T from ACE has some useful enhancements in this direction. BTW, it seems that with int ticks and HZ of 1000, ticks would overflow from INT_MAX to INT_MIN in ~24 days. I can imagine that some code might get confused by such an overflow. But that's a different topic. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 21:03:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A327106566C for ; Sat, 18 Feb 2012 21:03:01 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id CDED58FC16 for ; Sat, 18 Feb 2012 21:03:00 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id bZ0X1i0041c6gX854Z319y; Sat, 18 Feb 2012 21:03:01 +0000 Received: from hans3 ([66.30.197.229]) by omta23.westchester.pa.mail.comcast.net with comcast id bZ2z1i00j4xSlmi3jZ30Db; Sat, 18 Feb 2012 21:03:01 +0000 Received: from algo by hans3 with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyrQo-000KHS-MF; Sat, 18 Feb 2012 16:02:58 -0500 From: Alex Goncharov To: bf1783@gmail.com In-reply-to: (bf1783@googlemail.com) References: Message-Id: Sender: Alex Goncharov Date: Sat, 18 Feb 2012 16:02:58 -0500 Cc: freebsd-hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:03:01 -0000 ,--- b. f. (Sat, 18 Feb 2012 20:50:01 +0000) ----* | Most of these questions are more suitable for the freebsd-stable or | freebsd-questions mailing lists, rather than freebsd-hackers. I hesitated about starting this "8 to 9" thread here or on *-stable, and decided to use this list only because I had started another "8 to 9" thread re BIOS (applicable to current or legacy) on this list a couple of days before. So, it's here for consistency with the first thread but would be "there" otherwise. Don't mean I was right... Thank you for your very detailed response -- I will follow your advice and documentation pointers! -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 21:10:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65EF7106566C for ; Sat, 18 Feb 2012 21:10:54 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5418FC12 for ; Sat, 18 Feb 2012 21:10:53 +0000 (UTC) Received: by vcmm1 with SMTP id m1so4285560vcm.13 for ; Sat, 18 Feb 2012 13:10:53 -0800 (PST) Received-SPF: pass (google.com: domain of matthewstory@gmail.com designates 10.52.71.226 as permitted sender) client-ip=10.52.71.226; Authentication-Results: mr.google.com; spf=pass (google.com: domain of matthewstory@gmail.com designates 10.52.71.226 as permitted sender) smtp.mail=matthewstory@gmail.com; dkim=pass header.i=matthewstory@gmail.com Received: from mr.google.com ([10.52.71.226]) by 10.52.71.226 with SMTP id y2mr6810629vdu.78.1329599453312 (num_hops = 1); Sat, 18 Feb 2012 13:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VqdVM7Eyrb/LcWII9y+mtoWELyASJtHIRslvofayGC0=; b=pdcT8suYqUoAG/XJ0Yol4CVgSmbibVctKEOtIOhqEdm5IqtRoANbLgB8EjORXPub7/ xjE1vdFoAAAZXfVzvmkipyrfFTJP434PSxvBrc3OqVfDfrhBqFBeVBc12doPSnqcd+lA E0ujfy+QOmefwZZyYwT878UK28qr4NqZ1+6h4= MIME-Version: 1.0 Received: by 10.52.71.226 with SMTP id y2mr5488803vdu.78.1329599452655; Sat, 18 Feb 2012 13:10:52 -0800 (PST) Received: by 10.52.21.84 with HTTP; Sat, 18 Feb 2012 13:10:52 -0800 (PST) In-Reply-To: References: <20120214193530.GA42580@stack.nl> Date: Sat, 18 Feb 2012 16:10:52 -0500 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: xargs short-circuit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:10:54 -0000 On Tue, Feb 14, 2012 at 3:25 PM, Matthew Story wrote: > On Tue, Feb 14, 2012 at 2:37 PM, Matthew Story wrote: > >> On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker wrote: >> >>> On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: >>> > After reading the man-page, and browsing around the internet for a >>> minute, >>> > I was just wondering if there is an option in (any) xargs to >>> short-circuit >>> > on first failure of [utility [arguments]]. >>> >>> > e.g. >>> >>> > $ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || >>> echo $? >>> > 1 >>> > 1 >>> >>> > such that any non-0 exit code in a child process would cause xargs to >>> stop >>> > processing. seems like this would be a nice feature to have. >>> >>> As per xargs(1), you can do this by having the command exit on a signal >>> or with a value of 255. >>> >> > exit 255 with -P, and SIGTERM (with or without -P) causes FreeBSD xargs to > orphan, is this desirable behavior? findutils xargs orphans on 255 and > SIGTERM (with -P), but does not orphan without -P when SIGTERM is sent. I > would expect xargs to propegate the signal, or wait, although the man page > does say "immediately", the POSIX specification is less clear ... this > makes it more-or-less unsuitable for my needs, but i guess i could do > something like: > > ... | xargs sh -c '... exit 255;' > if [ $? -ne 0 ]; then > wait > # cleanup > exit 1 > fi > I have patched xargs behavior on exit 255 from utility, or termination of utility via signal to wait on existing utility processes before exiting 1. This make the exit 255 behavior much more predictable. I sent a lengthier explanation of the patch and reasoning to arch@, but figured I would follow up in thread as well. Patch available here: http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.patch.txt Hoping this patch will make it back into xargs, it makes exit 255 predictable with -P > 1. > > >> >> Yes indeed it does ... should have scoured further, thanks! >> >> >>> >>> -- >>> Jilles Tjoelker >>> >> >> >> >> -- >> regards, >> matt >> > > > > -- > regards, > matt > -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 21:15:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97DC8106564A for ; Sat, 18 Feb 2012 21:15:56 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2258F8FC08 for ; Sat, 18 Feb 2012 21:15:55 +0000 (UTC) Received: by werm13 with SMTP id m13so3975494wer.13 for ; Sat, 18 Feb 2012 13:15:55 -0800 (PST) Received-SPF: pass (google.com: domain of bf1783@googlemail.com designates 10.180.86.134 as permitted sender) client-ip=10.180.86.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bf1783@googlemail.com designates 10.180.86.134 as permitted sender) smtp.mail=bf1783@googlemail.com; dkim=pass header.i=bf1783@googlemail.com Received: from mr.google.com ([10.180.86.134]) by 10.180.86.134 with SMTP id p6mr5993158wiz.0.1329599755231 (num_hops = 1); Sat, 18 Feb 2012 13:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=O/sN1CLV5AM7GJpsGHQR+sgTvHYAD1FUCWEbEy4mGsA=; b=AnoQPIB+CCU/sBqG2erErCM6eOtVeA4Kt/y5O1PmoIvAQ0Ay9Bngfjl0csgo6krIWf 1/rHP++Oayp+9mW38VKOu+lQ4/kd0iBOYfDIdwaLpacHiWbh+LJAUkE+IkEX+Bpd7cbH Sj2IV85W5jteLj6LfYkxDgR2iHx5VlpNge0qA= MIME-Version: 1.0 Received: by 10.180.86.134 with SMTP id p6mr4966574wiz.0.1329598201930; Sat, 18 Feb 2012 12:50:01 -0800 (PST) Received: by 10.180.126.69 with HTTP; Sat, 18 Feb 2012 12:50:01 -0800 (PST) Date: Sat, 18 Feb 2012 20:50:01 +0000 Message-ID: From: "b. f." To: freebsd-hackers@freebsd.org, Alex Goncharov Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:15:56 -0000 Most of these questions are more suitable for the freebsd-stable or freebsd-questions mailing lists, rather than freebsd-hackers. Alex Goncharov wrote: > What I see in 9 now is very confusing for me; e.g.: > > * Why 'snd_hda.ko' even exists, if the whole 'snd_hda' implementation lives in > 'kernel' now? > > If not the whole, why is it split between 'kernel' and 'snd_hda.ko'? > The implementation is not split between the kernel and the module: the snd_hda components are redundant. By default, most of the kernel modules are built and installed, even those present in GENERIC, unless one removes them from the build with MODULES_OVERRIDE or WITHOUT_MODULES (see, for example, make.conf(5)). This is because users often build one or more kernels that may not have all of the components that are in GENERIC. You can easily remove the modules that you don't want. > * Why did 'snd' earn the honor to live in 'kernel', but 'linux.ko' did > not? Because some people requested it, and no developer objected. Different users have different requirements, and most people can find parts of GENERIC that they don't want or need. Fortunately, users can easily build a custom kernel. If you don't want to be bothered with constructing a minimal custom kernel, but just want to remove a few components from GENERIC, you could use a simple custom kernel configuration like: include GENERIC ident MUTEGENERIC nodevice sound , snd_es137x , snd_hda , snd_ich , snd_uaudio , snd_vida8233 See, for example, config(5). > * And what about CAM? ... > Should I now (in 9) have: ... > atapicam_load="YES" ... > as I had in 8, or it's no longer necessary because of the above > extract from /usr/src/sys/amd64/conf/GENERIC? If you are using ATA_CAM, then you should not be using atapicam. I suspect that an explicit discussion of this is missing from some of the manpages because developers were planning to remove the old ATA code, and didn't want to spend a lot of time rewriting those documents, only to change or remove them later. But this has been mentioned several times on various lists, and is documented in src/sys/conf/NOTES: # ATA_CAM: Turn ata(4) subsystem controller drivers into cam(4) # interface modules. This deprecates all ata(4) # peripheral device drivers (atadisk, ataraid, atapicd, # atapifd, atapist, atapicam) and all user-level APIs. # cam(4) drivers and APIs will be connected instead The cd(4) driver in 9.0 should work adequately for most CDs, although you may want to add some post-release fixes from 9-STABLE, like: http://svnweb.FreeBSD.org/base?view=revision&revision=230014 ... > | I keep hoping that if I repeat this enough times that people will get > | the word. :) Because loading modules through loader.conf is > | veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called > | kld that will load the specified modules after disks are mounted. This > | is at least an order of magnitude faster. Look for kld_list in > | rc.conf(5) if you want the details, but the short version is that you > | just do something like, kld_list="umass coretemp ichwd linux nvidia". > | This is in all the -stable branches (including 7), is already in 9.0, > | and will be in 8.3. > > I will use this -- thank you! You should be aware that kld_list doesn't always work. For example, my Nvidia nForce MCP61 network adapter works with nfe(4) when I load if_nfe.ko from loader.conf, but fails to function properly if the same module is loaded via kld_list, spamming the console with messages like: "... kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering" when I attempt to establish a connection over it. b. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 23:18:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A57106566B for ; Sat, 18 Feb 2012 23:18:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id CE8618FC08 for ; Sat, 18 Feb 2012 23:18:14 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3510053wib.13 for ; Sat, 18 Feb 2012 15:18:13 -0800 (PST) Received-SPF: pass (google.com: domain of adrian.chadd@gmail.com designates 10.180.95.105 as permitted sender) client-ip=10.180.95.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adrian.chadd@gmail.com designates 10.180.95.105 as permitted sender) smtp.mail=adrian.chadd@gmail.com; dkim=pass header.i=adrian.chadd@gmail.com Received: from mr.google.com ([10.180.95.105]) by 10.180.95.105 with SMTP id dj9mr6408424wib.18.1329607093836 (num_hops = 1); Sat, 18 Feb 2012 15:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ltq4if404rVklF5DbybBH59vpI8/2CUadW87Wx4BOzI=; b=c+77M7sUSTHUcEi73RGL47K3ZInrtZ/4V8VS10khPvL9m05Zse9q1ZNztqZM3S13PS aSZqmnHCiY3+4rE9lbqv35GvANnm2Oyrg/6321bsS6/BE/O0puChRz+Wz1Q2eMVsf86W 9M/fYfcQjiBwzyBcR4Biiai7qAwQDdGVSTpys= MIME-Version: 1.0 Received: by 10.180.95.105 with SMTP id dj9mr5381140wib.18.1329607093793; Sat, 18 Feb 2012 15:18:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Sat, 18 Feb 2012 15:18:13 -0800 (PST) In-Reply-To: References: Date: Sat, 18 Feb 2012 15:18:13 -0800 X-Google-Sender-Auth: 1UW6EZl9F_hANpN9dKc5COHtPNI Message-ID: From: Adrian Chadd To: bf1783@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alex Goncharov Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 23:18:15 -0000 On 18 February 2012 12:50, b. f. wrote: >> I will use this -- thank you! > > You should be aware that kld_list doesn't always work. =A0For example, > my Nvidia nForce MCP61 network adapter works with nfe(4) when I load > if_nfe.ko from loader.conf, but fails to function properly if the same > module is loaded via kld_list, spamming the console with messages > like: > > "... kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering" > > when I attempt to establish a connection over it. Is there a PR for this? Adrian From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 22:16:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D6BB106568F; Sat, 18 Feb 2012 22:16:52 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id DEAB68FC17; Sat, 18 Feb 2012 22:16:51 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 6266756203; Sat, 18 Feb 2012 16:16:51 -0600 (CST) Date: Sat, 18 Feb 2012 16:16:51 -0600 From: Mark Linimon To: freebsd-hackers@freebsd.org Message-ID: <20120218221651.GB1240@lonesome.com> References: <20120119005658.218280@gmx.com> <4F19188A.4090907@herveybayaustralia.com.au> <4F213CEB.4020207@herveybayaustralia.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F213CEB.4020207@herveybayaustralia.com.au> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 18 Feb 2012 23:20:51 +0000 Cc: linimon@FreeBSD.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 22:16:52 -0000 On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: > 1. Incidentally, what exactly does constitute a major release? That point in time where we guarantee that we break a certain degree of backwards compatibility. (Well, that's the key component. Feature- additions ride on top of that.) > 2. Is there a reason to update the numbers so quickly? Yes, so that we don't have to keep supporting backwards compatibility for as long a period (see 1) -- it's a significant burden to maintain. It's necessary to do these as we rework things like network layers for higher performance, rework wireless to work with modern devices, and other high-demand items. > 3. Could a higher bar be set to reach a major release than simply > temporal objectives? Yes. We did that with 5.x, and blew it big-time. The goal of "rewrite the entire system to support SMP in a scalable, reliable fashion" was simply too aggressive. It led to ~5 years between major releases, and by that time the system had changed very dramatically (SMP, suspend/resume, IIRC GEOM, and too many other things to list). It was a huge jump and the learning curve for upgrading was way too large. We lost userbase. Also, keeping 5 years between major releases led to very high developer frustration. Why work on something when it will take 4+ years to even see the light of day? This is why we moved to the time-based releases. 18 months was seen as a compromise between all the various demands. Even so, we are almost exactly at 24 months in practice; see the graphs I updated last month as a result of all the recent discussion: http://people.freebsd.org/~linimon/schedule/ My own view is that 5 years between major releases is not going to happen, due to how painful the 5.x experience was for all concerned. But as I'm not a src committer, I'm not one of the people who will be picking the interval for our major-branch timeline. I just try to graph it as it goes by. mcl From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 23:58:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A38106566B; Sat, 18 Feb 2012 23:58:59 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05B1B8FC16; Sat, 18 Feb 2012 23:58:58 +0000 (UTC) Received: by daec6 with SMTP id c6so5120427dae.13 for ; Sat, 18 Feb 2012 15:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ubfcBdH/zFGY5jXKVzPEL8CNSy2dKIP308XO37YIHZ4=; b=kSPmI1nf3n+pLQPA8kqK06S1gss5empxLquYASmJp4kB+svcZ80KE3g1apmtCc0V8K FeOhzDTRLwwpcE2z0cPNib79tE0qqP5ijGby7UMZia/N1OAeAZ1KfUA0D9OMbg6GWiFz zWqxabWoQVrG1l0thamnLalRLp3r3QhpGx4Zs= MIME-Version: 1.0 Received: by 10.68.211.131 with SMTP id nc3mr36150998pbc.49.1329607739340; Sat, 18 Feb 2012 15:28:59 -0800 (PST) Received: by 10.68.48.35 with HTTP; Sat, 18 Feb 2012 15:28:59 -0800 (PST) In-Reply-To: <20120218221651.GB1240@lonesome.com> References: <20120119005658.218280@gmx.com> <4F19188A.4090907@herveybayaustralia.com.au> <4F213CEB.4020207@herveybayaustralia.com.au> <20120218221651.GB1240@lonesome.com> Date: Sat, 18 Feb 2012 18:28:59 -0500 Message-ID: From: Super Bisquit To: Mark Linimon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, linimon@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 23:58:59 -0000 The individual maintainers of each architecture have the right to make a "PRE-RELEASE" of the system at any time. Come to think of it, anyone who can has that right- that is to make a pre-release. On 2/18/12, Mark Linimon wrote: > On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: >> 1. Incidentally, what exactly does constitute a major release? > > That point in time where we guarantee that we break a certain degree > of backwards compatibility. (Well, that's the key component. Feature- > additions ride on top of that.) > >> 2. Is there a reason to update the numbers so quickly? > > Yes, so that we don't have to keep supporting backwards compatibility > for as long a period (see 1) -- it's a significant burden to maintain. > It's necessary to do these as we rework things like network layers for > higher performance, rework wireless to work with modern devices, and > other high-demand items. > >> 3. Could a higher bar be set to reach a major release than simply >> temporal objectives? > > Yes. We did that with 5.x, and blew it big-time. The goal of "rewrite > the entire system to support SMP in a scalable, reliable fashion" was > simply too aggressive. It led to ~5 years between major releases, and by > that time the system had changed very dramatically (SMP, suspend/resume, > IIRC GEOM, and too many other things to list). It was a huge jump and > the learning curve for upgrading was way too large. We lost userbase. > > Also, keeping 5 years between major releases led to very high developer > frustration. Why work on something when it will take 4+ years to even > see the light of day? > > This is why we moved to the time-based releases. 18 months was seen as > a compromise between all the various demands. Even so, we are almost > exactly at 24 months in practice; see the graphs I updated last month as > a result of all the recent discussion: > > http://people.freebsd.org/~linimon/schedule/ > > My own view is that 5 years between major releases is not going to happen, > due to how painful the 5.x experience was for all concerned. But as I'm > not a src committer, I'm not one of the people who will be picking the > interval for our major-branch timeline. I just try to graph it as it > goes by. > > mcl > _______________________________________________ > 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" >