From owner-freebsd-arch@FreeBSD.ORG Sun Feb 5 19:22:03 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83FA4106566B for ; Sun, 5 Feb 2012 19:22:03 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 27E898FC0A for ; Sun, 5 Feb 2012 19:22:02 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 354897A4; Sun, 5 Feb 2012 20:22:01 +0100 (CET) Date: Sun, 5 Feb 2012 20:20:45 +0100 From: Pawel Jakub Dawidek To: Konstantin Belousov Message-ID: <20120205192045.GH30033@garage.freebsd.pl> References: <20120203193719.GB3283@deviant.kiev.zoral.com.ua> <20120205114345.GE30033@garage.freebsd.pl> <20120205164729.GH3283@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IbVRjBtIbJdbeK1C" Content-Disposition: inline In-Reply-To: <20120205164729.GH3283@deviant.kiev.zoral.com.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: Prefaulting for i/o buffers 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 Feb 2012 19:22:03 -0000 --IbVRjBtIbJdbeK1C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 05, 2012 at 06:47:29PM +0200, Konstantin Belousov wrote: > On Sun, Feb 05, 2012 at 12:43:46PM +0100, Pawel Jakub Dawidek wrote: > > @@ -199,6 +200,7 @@ thread_init(void *mem, int size, int flags) > > =20 > > td->td_sleepqueue =3D sleepq_alloc(); > > td->td_turnstile =3D turnstile_alloc(); > > + td->td_rlqe =3D rlqentry_alloc(); > >=20 > > What is the purpose of td_rlqe field? From what I see thread can lock > > more than one range. Could you elaborate on that as well? > td_rlqe is a cached rangelock entry used for the typical case of the > thread not doing recursive i/o. In this case, it is possible to avoid > memory allocation on the i/o hot path by using entry allocated during > thread creation. Since thread creation already allocates many chunks > of memory, and typical thread performs much more i/o then it suffers > creation, this shorten the i/o calculation path. I see. I'd be in favour of dropping entry allocation on thread creation. This would make the allocation lazy and it will be done on the first I/O only. What do you think? Thread creation should be fast, so if we can avoid adding up, I would go that route. > > This is a bit hard to understand immediately. Maybe something like the > > following is a bit more readable (I assume this goto could happen only > > once): > >=20 > > len =3D MIN(uio->uio_iov->iov_len, io_hold_cnt * PAGE_SIZE); > > addr =3D (vm_offset_t)uio->uio_iov->iov_base; > > end =3D round_page(addr + len); > > if (howmany(end - trunc_page(addr), PAGE_SIZE) > io_hold_cnt) { > > len -=3D PAGE_SIZE; > > end =3D round_page(addr + len); > > } > I think it can happen twice, if both start and len are perfectly mis-alig= ned. I see. That make sense. It would be nice to add comment there, as it wasn't immediately obvious (at least for me) what's going on. Another way to simplify this piece of code would be to either make ma[] array of 'io_hold_cnt + 2' elements or set 'len' to '(io_hold_cnt - 2) * PAGE_SIZE'. Short comment describing why we add or subtract 2 would be of course welcome. Just curious, why io_hold_cnt is 'static const int' instead of define? > http://people.freebsd.org/~kib/misc/vm1.8.patch The new patch looks good to me. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --IbVRjBtIbJdbeK1C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8u1o0ACgkQForvXbEpPzT+QwCgjkC5udmjk3NQxu/ktUgozX2o DMEAmQGsHDmZR0yBw563Ot6O8ivKYwSB =k7WD -----END PGP SIGNATURE----- --IbVRjBtIbJdbeK1C--