From owner-svn-src-head@FreeBSD.ORG Thu Sep 3 17:38:08 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F2801065693; Thu, 3 Sep 2009 17:38:08 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD3D8FC2E; Thu, 3 Sep 2009 17:38:07 +0000 (UTC) Received: by ewy4 with SMTP id 4so147605ewy.36 for ; Thu, 03 Sep 2009 10:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=AOeaKyZUL6WLPgseCelL2Vung470mrNHW8zMD3l1930=; b=N4qeNc4viqpD4XcZVjGOquqqhMc/qGX8nLyNSlDFGAhtnkwQ/cYp8q5lxD4mrvP75Y Hx/6EnDeJXXqu862Ot/vJts3eeifVCYqH/RNyehJJNAZpT0u5IG7LhXEm2ypAaB3r/pV rxr8wLu5qCBC+vfRzvoTCLdoVALl2/f98m3Tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=CXIHhPgBMpSlMVLVanWSYfok24EY1ZRQkjcc55Ks0b1jqM8uELgCPwX+fe/+PElA9+ IAIKmovMsqbXlewzCMbZhWA9sNPtRiNbs79U28H8bKkPpw3xkS3eozBDRjyZ6bD59cG+ KlqZuFMzllU7sxihdK1xw8hGD1mZJ1tFUCano= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.90.6 with SMTP id d6mr577632wef.95.1251999486092; Thu, 03 Sep 2009 10:38:06 -0700 (PDT) In-Reply-To: <20090903095224.N20031@pooker.samsco.org> References: <200909031237.n83CbIgk032551@svn.freebsd.org> <1872D962-9297-4C45-9F73-4BB823C49D74@samsco.org> <4A9FD8B4.2080605@FreeBSD.org> <20090903095224.N20031@pooker.samsco.org> From: Ivan Voras Date: Thu, 3 Sep 2009 19:37:46 +0200 X-Google-Sender-Auth: 6ab0e7c9b196fb06 Message-ID: <9bbcef730909031037y4aecd692t4812718b1fd7e78e@mail.gmail.com> To: Scott Long Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, Alexander Motin , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r196777 - head/sys/dev/ahci X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 03 Sep 2009 17:38:08 -0000 2009/9/3 Scott Long : > On Thu, 3 Sep 2009, Alexander Motin wrote: >> It would be nice if every level would do it's own job. > > It's the job of the driver to handle the limitations of the hardware, yes= . > Again, if you want to experiment with pushing this functionality into GEO= M, > be my guest. =C2=A0But until then, consider following my advice. Speaking as an user who goes "huh, well" every time he sees a RAID card with a GB of cache talking to the OS in 64 kB chunks, eventually removing this limitation seems a Nice Thing to Have. I don't know how things look at the driver side, but GEOM by itself has no problems passing around requests of at least "long" in length. Specifically, it cares about struct bio, where bio_bcount is a "long" and bio_length and bio_completed are off_t. So, ssize_t looks ok as a high boundary. There was a time (apparently much of it was a bug in reporting and is now fixed :( ) when MAXPHYS could be manually redefined to be 256K or more and iostat would nicely state the higher value. I think the concern raised at the topic was that it doesn't play nice with bufcache, and I think the specific problem was possible out-of-memory situations. Now that kernel limits on AMD64 are much increased (to values not longer fitting in uint32_t) I wonder if the problem is so serious? I also remember BSDCan 2008: http://wiki.freebsd.org/Buf0x :) --=20 f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A=3D=3D