From owner-svn-src-head@freebsd.org Fri Aug 19 09:35:35 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89A10BBFA8A; Fri, 19 Aug 2016 09:35:35 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp004.me.com (st13p35im-asmtp004.me.com [17.164.199.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CA381CCC; Fri, 19 Aug 2016 09:35:35 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp004.me.com by st13p35im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OC500N00GZUON00@st13p35im-asmtp004.me.com>; Fri, 19 Aug 2016 09:35:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1471599334; bh=m2j7mQzR1uPalnh8tIjmkZPL2B345cMzYeS0VhsT6qw=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=kqSjg6pFmykO+7l//pw19lQ3df9mbMag/+/KQXs1IrsoLD//lW7/PRKUixnzzaRks +yR5T8dFNBDMIbYCxPw2B4gODQWIoRlj4/aEw/0LLlZFvzXKA5QAfgsOy8rFyn/LeI VDbq9E3wQZUGAWkG2Ez456vcEF0tgwvqUxdGcxS5OQ3LFL95Cn2iRIu2vUDMX6aIqC DCglSHQetlfOO2AeEoGVWWAq6hVQGgs69yLclSCzPzQoSWosuY7MqJF5v+P68xiJXL AJP6GenJ0V0HBs4rPjA7zWOKx+PWoMFL73aaApc4nJYsLP96BH9Ipd3aItl5EPZbLO fdUyeeuswv8OA== Received: from [88.196.10.181] (181-10-196-88.dyn.estpak.ee [88.196.10.181]) by st13p35im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OC5002VVHB6Z210@st13p35im-asmtp004.me.com>; Fri, 19 Aug 2016 09:35:34 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-19_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1608190124 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd From: Toomas Soome In-reply-to: <20160819092424.GE83214@kib.kiev.ua> Date: Fri, 19 Aug 2016 12:35:30 +0300 Cc: Warner Losh , Julian Elischer , John Baldwin , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-transfer-encoding: quoted-printable Message-id: <514987E4-B953-467C-B53B-824B172A5211@me.com> References: <201608152038.u7FKc2NL026330@repo.freebsd.org> <2065331.KaGOSftJhd@ralph.baldwin.cx> <0d6c2e45-e4da-9bb7-a50c-212135d9ac4f@freebsd.org> <20160819073955.GC83214@kib.kiev.ua> <50AAF049-C8A7-4C69-A206-C3983FFA7867@me.com> <20160819092424.GE83214@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3124) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 09:35:35 -0000 > On 19. aug 2016, at 12:24, Konstantin Belousov = wrote: >=20 > On Fri, Aug 19, 2016 at 11:50:35AM +0300, Toomas Soome wrote: >>=20 >>> On 19. aug 2016, at 10:39, Konstantin Belousov = wrote: >>>=20 >>> On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote: >>>> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer = wrote: >>>>> On 16/08/2016 4:54 AM, John Baldwin wrote: >>>>>>=20 >>>>>> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote: >>>>>>>=20 >>>>>>> Author: jhb >>>>>>> Date: Mon Aug 15 20:38:02 2016 >>>>>>> New Revision: 304187 >>>>>>> URL: https://svnweb.freebsd.org/changeset/base/304187 >>>>>>>=20 >>>>>>> Log: >>>>>>> Remove the mcd(4) driver for Mitsumi CD-ROM players. >>>>>>> This is a driver for a pre-ATAPI ISA CD-ROM adapter. As = noted in >>>>>>> the manpage, this driver is only useful as a backend to = cdcontrol to >>>>>>> play audio CDs since it doesn't use DMA, so its data performance = is >>>>>>> "abysmal" (and that was true in the mid 90's). >>>>>>=20 >>>>>> No one stepped up to test patches for it either when I last = posted patches >>>>>> to >>>>>> convert it from timeout(9) to callout(9). I have a few more = drivers that >>>>>> are >>>>>> both very old and that people have no business using in 12 (think = ISA >>>>>> adapters that don't do DMA and can't be used with pccard) that I = will be >>>>>> removing over the next little while. I brought up a list of = drivers on >>>>>> arch@ >>>>>> a couple of years ago and the conversation drifted off into the = weeds >>>>>> about >>>>>> trimming GENERIC, etc. No one objected to the specific drivers I = listed >>>>>> though (and I got a few pleas of "please remove"). If someone = shows up >>>>>> desperately clutching an ISA adapter they can always dig up the = source >>>>>> from >>>>>> svn and deal with forward porting it for whatever API changes = have >>>>>> happened >>>>>> since it was removed. >>>>>=20 >>>>>=20 >>>>> I would imagine any machine still holding one of these probably = has not >>>>> enough memory to run FreeBSD. >>>>>=20 >>>>> would we still run in 2MB? >>>>=20 >>>> With insane levels of tuning, we can run in 32MB userland that can = do >>>> things. Even 64MB is tight w/o some tuning. 16MB is almost = certainly >>>> right out except for very specialized situations. 2MB? We can't = even >>>> load the loader in that :(. Oh, and all these memory configs are = only >>>> possible if you tweak the loader's block cache... >>>>=20 >>>=20 >>> 32MB is quite usable. Without any tuning, you get slightly less = than 10MB >>> for userspace, which is enough to for many things, and plenty if = swap is >>> added. >>>=20 >>> Note that you cannot boot on such configurations since loader was = broken, >>> but if you do manage to jump to kernel, things were fine several = months >>> ago. I tested my relatively recent OOM changes on 32MB qemu config. >>>> Warner >>>=20 >>=20 >> If the target is to go as low memory as possible, sure, you can strip = all off, from boot loader point, you should load kernel from stage2 and = not use loader at all (you can load and jump kernel even now from = stage2, assuming it wont need any special configuration from loader = config) etc etc. This means highly specialized build and has nothing to = do with generic all purpose system. >>=20 > Why you describe this as an 'alternative' ? Before that loader = changes, > I regularly tested on 32MB qemy i386 image and 64MB amd64 image. I do > not see anything extreme in these configs. They use normal boot path, > which provides kernels with debugging symbols, metadata, loaded = modules > etc. Why should I use deficient boot2-only loading, which, = additionally, > cannot work on amd64 ? >=20 > More, this is the only reasonable way for most developers to ensure = that > system is still usable on tiny configs found on embedded devices. = Right > now the min which I have to set up is 128MB, and VM changes are simply = not > tested on anything smaller. It is guaranteed that small systems will = grow > regressions fast. And I will not jump through the hoops to mitigate > breakage induced by other people' changes. >=20 >> Also at some point, there is an question about how reasonable it is = to have such configuration as part of generic code base for special bits = like boot loader itself, as the problem is, testing all those variants = is becoming impossible and even keeping reasonable code base in all of = the #if #else #endif spaghetti is getting quite hard and error prone. >>=20 >>> =46rom developers point of view, it is not really encouraging to = have possible feedback like ???oh, but you did break my 32MB system = boot??? ;) This does bring back some memories however. For first 2 unix = systems I was dealing with, one had 8MB and another had 12MB of = memory??? it was ~ 1992-1993;) >>=20 > Not mine, but you (?) indirectly broke system for people who do use = 32MB > on other arches, since low memory config on dev systems become 128MB. > I cared about 32MB before, but not any longer. Yep, I did set it to 64MB. And this is exactly why I wrote that small = systems do need special approaches, because getting updates for new = features and keeping tiny systems functional are conflicting options. So = far freebsd boot loader has managed this in some extent by massive = amount of preprocessor conditions and the result is insane list of = different boot programs in /boot - this is the price to pay. Even to = install the boot program you need to know when to use gpart and when = dd=E2=80=A6 rgds, toomas >=20 >> Right now the loader and stage2 are set to use 64MB heap to make it = possible to implement zfs feature support and later on, for more = features. >>=20 >> Also note that UEFI setups are much harder to deal with regard of = memory management, because as long as BS are in control, you can not = really control the memory management there and can end up with = fragmented unusable (for kernel loading) layout. This is especially = nasty as apparently some (buggy) systems actually have runtime services = using boot services memory areas, so you can end up in setup where you = can not re-use BS memory and those chunks can be all over the low memory = address space???=20 >=20 > Yes, I do suspect that eventually systems appear where our default > layout of the kernel physical segments is not workable and both loader > and kernel bootstrap would need to grow much more flexibility. Initial > 1GB-idmap page table structure and kernel page table would need to = handle > this, and we will need a kernel relocator either in loader or in = kernel > itself.