From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 07:56:10 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF7716A418 for ; Fri, 2 Nov 2007 07:56:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8648E13C447 for ; Fri, 2 Nov 2007 07:56:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com ([62.64.120.197]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Inhc4-000EWE-9S for freebsd-hackers@freebsd.org; Thu, 01 Nov 2007 23:30:04 +0200 Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Inhc1-0003Nw-Gs for freebsd-hackers@freebsd.org; Thu, 01 Nov 2007 23:30:03 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lA1LTvho087278; Thu, 1 Nov 2007 23:29:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id lA1LTvf3087277; Thu, 1 Nov 2007 23:29:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 1 Nov 2007 23:29:57 +0200 From: Kostik Belousov To: "Arno J. Klaassen" Message-ID: <20071101212957.GZ37471@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yTwVabqJa5IUz21H" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 962db39f35b00980c0b011075312dce6 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1727 [Nov 01 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-hackers@freebsd.org Subject: Re: "indefinite" wait buffer patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 07:56:10 -0000 --yTwVabqJa5IUz21H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 01, 2007 at 09:20:42PM +0100, Arno J. Klaassen wrote: > Hello, >=20 >=20 > while slowly testing releng_7, I remembered I have since about > two years the attached diff in my releng_6 sources (patch > recreated against releng_7 with low timeouts for debugging) : >=20 > it addresses the situation when one creates a huge swap-space on=20 > a (relatively) slow disk-subsystem : e.g. for scientific computing > it sometimes makes sense to have, e.g. 8G swap for 2G main memory > if you know you're treating N less then 2G matrices and process > is CPU-bound for quite a while for 1 matrix before switching to=20 > the other. > But then, when switching from one matrix to another, dmesg gets > flooded by : >=20 > "indefinite wait buffer"=20 >=20 > messages. >=20 > The attached patch shows in fact that the wait buffer is never > "indefinite" (unless a real HW-problem probably) and linearly > increases timeout to match with reality. I think this is mostly good. See below. >=20 > The last chunk is just to prevent for a panic at reboot when > there is so much data swapped out that is doesn't get treated > before 'reboot-finish-time-out'. This chunk would cause (non-silent) data corruption. Besides reboot, the code is used when swap is turned off on live system. Index: sys/vm/swap_pager.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.295 diff -u -r1.295 swap_pager.c --- sys/vm/swap_pager.c 5 Aug 2007 21:04:32 -0000 1.295 +++ sys/vm/swap_pager.c 1 Nov 2007 18:59:18 -0000 @@ -941,6 +941,10 @@ =2E.. + static int timo_secs =3D TIMO_START; =2E.. + if (retry*TIMO_CHUNK > timo_secs) { + timo_secs =3D retry*TIMO_CHUNK; Imagine that two buffers got the timeout on swap-in simultaneously. I think that, instead, making timo_secs local variable would be right. Also, timeout reading one buffer shall not increase the timeout swapping in another one. --yTwVabqJa5IUz21H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHKkVUC3+MBN1Mb4gRAgjWAKDJrXg8thPMtMTC8wHGbSsYjsWXLgCguYBd s4RAJQ+rNiAF7Qh9apE/qz0= =c0cx -----END PGP SIGNATURE----- --yTwVabqJa5IUz21H--