From owner-freebsd-arch@FreeBSD.ORG Sun Jul 5 08:38:38 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9DE1106564A for ; Sun, 5 Jul 2009 08:38:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 33B9B8FC12 for ; Sun, 5 Jul 2009 08:38:37 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247673270; Sun, 05 Jul 2009 11:38:35 +0300 Message-ID: <4A50667F.7080608@FreeBSD.org> Date: Sun, 05 Jul 2009 11:38:23 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> In-Reply-To: <20090705100044.4053e2f9@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: DFLTPHYS vs MAXPHYS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 08:38:38 -0000 Gary Jennejohn wrote: > On Sat, 04 Jul 2009 22:14:53 +0300 > Alexander Motin wrote: > >> Can somebody explain me a difference between DFLTPHYS and MAXPHYS >> constants? As I understand, the last one is a maximal amount of memory, >> that can be mapped to the kernel, or passed to the hardware drivers. But >> why then DFLTPHYS is used in so many places and what does it mean? > > There's a pretty good comment on these in /sys/conf/NOTES. But it does not explains why. >> Isn't it a time to review their values for increasing? 64KB looks funny, >> comparing to modern memory sizes and data rates. It just increases >> interrupt rates, but I don't think it really need to be so small to >> improve interactivity now. > > Probably historical from the days when memory was scarce. > > There's nothing preventing the user from upping these values in his > kernel config file. But note the warning in NOTES about possibly > making the kernel unbootable. It's not clear whether this warning is > still valid given todays larger memory footprints and the inmproved > VM system. > > I wonder whether all drivers can correctly handle larger values for > DFLTPHYS. There are always will be drivers/devices with limitations. They should just be able to report that limitations to system. This is possible with GEOM, but it doesn't looks tuned well for all providers. There are many places, when DFLTPHYS used just with hope that it will work. IMHO if driver unable to adapt to any defined DFLTPHYS value, it should not use it, but instead should announce some specific value that it really supports. -- Alexander Motin