From owner-freebsd-arch Wed Mar 21 13:38:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B0E8C37B71E; Wed, 21 Mar 2001 13:38:21 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LLc8a21690; Wed, 21 Mar 2001 13:38:08 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 13:38:08 -0800 (PST) From: Matt Dillon Message-Id: <200103212138.f2LLc8a21690@earth.backplane.com> To: Poul-Henning Kamp Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89046.985209441@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When I last discussed MAXPHYS with people the issue that was predominant was the b_pages[] array embedded in the struct buf and the pages[] arrays declared in the VM paging code. I was worried that an increased MAXPHYS eating too much kernel stack and too much kernel memory. We also have the issue of the physical buffers (pbufs) reserving VM space permanently. If you increase MAXPHYS you quickly start to hit kernel VM limitations. There are also issues with I/O piplining and deadlock avoidance in the VFS/BIO subsystem. The VM low memory handling is effectively tuned to the assumption that MAXPHYS is somewhere 'around' 128K. Some initial-value work for VM related sysctls would be required there (minor work I think). There are also some minor issues associated with the clustering code. In anycase, my suggestion would be to leave it alone and instead work on optimizing the RAW DEVICE I/O path to not be limited by MAXPHYS at all. Increasing it to 256K might be possible, but increasing it to 1MB is out of the question (insofar as being a default). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message