From owner-freebsd-current@FreeBSD.ORG Mon Mar 22 02:00:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E831106564A; Mon, 22 Mar 2010 02:00:03 +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 8A4548FC18; Mon, 22 Mar 2010 02:00:02 +0000 (UTC) Received: by gyg13 with SMTP id 13so858788gyg.13 for ; Sun, 21 Mar 2010 19:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=lnt2qNgAuxpKpdjwMqwtOPKBUNHtTgq0InbXtTpmM/M=; b=Nl87VGlHgHZ3E9fLZDedJ1RIY5ohRk94naKPVyg0anuva6N8yvee9Q92Cd51mGA3D5 yQCjg269ytiPuA5cS6KKdh975ciD5fQ+piWe/onmyd6/h4T5Jddv4cC3Q+hifrb/pMnp F2VmuwIhaN+mWNx6T7p7MEee8CcBpYSxAdLoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=KnwlFLO7KAHKOiNCAsTxvOI9uoNy/UamB7ZaqvDPGZ/I9i15lq62RJrdbfSAnLNjj6 mgBo5i/ujKqBpsTK87mj1+stO34yVpx7P6HqA7lgPmjxEJVLWOyV4CNUmrhZLlRp6S5m nicdZkC2Rx+PpHnDB5LzknO8XL7qN1HgEyzO0= Received: by 10.90.40.17 with SMTP id n17mr3603308agn.3.1269223201919; Sun, 21 Mar 2010 19:00:01 -0700 (PDT) Received: from ppp-23.181.dialinfree.com (ppp-23.181.dialinfree.com [209.172.23.181]) by mx.google.com with ESMTPS id 22sm2697042iwn.4.2010.03.21.18.59.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 19:00:01 -0700 (PDT) Sender: "J. Hellenthal" Date: Sun, 21 Mar 2010 22:00:21 -0400 From: jhell To: Alexander Motin In-Reply-To: Message-ID: References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> <4BA62757.7090400@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 02:00:03 -0000 On Sun, 21 Mar 2010 20:54, jhell@ wrote: > > On Sun, 21 Mar 2010 10:04, mav@ wrote: >> Julian Elischer wrote: >>> In the Fusion-io driver we find that the limiting factor is not the >>> size of MAXPHYS, but the fact that we can not push more than >>> 170k tps through geom. (in my test machine. I've seen more on some >>> beefier machines), but that is only a limit on small transacrtions, >>> or in the case of large transfers the DMA engine tops out before a >>> bigger MAXPHYS would make any difference. >> >> Yes, GEOM is quite CPU-hungry on high request rates due to number of >> context switches. But impact probably may be reduced from two sides: by >> reducing overhead per request, or by reducing number of requests. Both >> ways may give benefits. >> >> If common opinion is not to touch defaults now - OK, agreed. (Note, >> Scott, I have agreed :)) But returning to the original question, does >> somebody knows real situation when increased MAXPHYS still causes >> problems? At least to make it safe. >> >> > > I played with it on one re-compile of a kernel and for the sake of it > DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash dump to > be performed upon request (reboot -d) due to the boundary being hit for DMA > which is 65536. Obviously this would have to be adjusted in ata-dma.c. > > I suppose that there would have to be a better way to get the real allowable > boundary from the running system instead of setting it statically. > > Other then the above I do not see a reason why not... It is HEAD and this is > the type of experimental stuff it was meant for. > > Regards, > > I should have also said that I also repeated the above without setting DFLTPHYS and setting MAXPHYS to 256. Regards, -- jhell