From owner-freebsd-ports@FreeBSD.ORG Thu Jul 26 22:45:56 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8B119106566B for ; Thu, 26 Jul 2012 22:45:55 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 5A36C23CFAA for ; Fri, 27 Jul 2012 00:38:05 +0200 (CEST) Message-ID: <5011C6CD.3040409@FreeBSD.org> Date: Fri, 27 Jul 2012 00:38:05 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org References: <20120724171842.GA47545@mech-cluster241.men.bris.ac.uk> <500F0CF7.4040209@FreeBSD.org> <20120725104729.GA92090@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20120725104729.GA92090@mech-cluster241.men.bris.ac.uk> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: Re: mutt 1.5 much slower than mutt 1.4 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 22:45:56 -0000 Am 25.07.2012 12:47, schrieb Anton Shterenlikht: > On Tue, Jul 24, 2012 at 11:00:39PM +0200, Matthias Andree wrote: >> Am 24.07.2012 19:18, schrieb Anton Shterenlikht: >>> mail/mutt is much slower on my amd64 and ia64 >>> -current boxes after it was updated from 1.4 >>> to 1.5. Each keystroke takes few seconds to >>> act. Below is my mutt 1.5 config: >> ... >> >>> Anybody else is seeing this behaviour? >> >> Not here™ on amd64 9-stable -- which may have little relevance for >> 10-current. >> >>> Any advice? >> >> Any chance to figure out what mutt is doing, like with truss or similar? > > I'll need to read up on this. I'm not sure if I can trust the truss WRT return values (looks like a 32 vs 64 bit issue), there tons of "unknown error". But there is a recurring action around dealing with /tmp/mutt-mech-cluster*. This I/O might be expensive, depending on the /tmp file system. RAM disk might be useful to speed things up... Any idea what's it doing? > getpid() = 4295169008 (0x1000313f0) > getpid() = 4295169008 (0x1000313f0) > lstat("/tmp/.muttJqtqdK",0x7fffffffffffc0a0) ERR#4295172128 'Unknown error: 204832' > mkdir("/tmp/.muttJqtqdK",0700) = 4295170448 (0x100031990) > open("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj",O_RDWR|O_NOFOLLOW|O_CREAT|O_EXCL,0600) = 4295170328 (0x100031918) > close(4) = 4295170688 (0x100031a80) > link("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj","/tmp/mutt-mech-cluster241-XSYQpzbj") = 4295170808 (0x100031af8) > lstat("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj",{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295172128 (0x100032020) > lstat("/tmp/mutt-mech-cluster241-XSYQpzbj",{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295172128 (0x100032020) > unlink("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj") = 4295170928 (0x100031b70) > unlink("/tmp/.muttJqtqdK/mutt-mech-cluster241-XSYQpzbj") ERR#4295170928 'Unknown error: 203632' > rmdir(0x7fffffffffffc878,0x1001b2c30,0x2,0x2,0x2,0xa0000000c813d400) = 0 (0x0) > open("/tmp/mutt-mech-cluster241-XSYQpzbj",O_RDWR|O_NOFOLLOW|O_CREAT,0600) = 4295170328 (0x100031918) > lstat("/tmp/mutt-mech-cluster241-XSYQpzbj",{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295172128 (0x100032020) > fstat(4,{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295171888 (0x100031f30) > fcntl(4,F_GETFL,) = 4295168408 (0x100031198) > fstat(4,{ mode=-rw------- ,inode=331538,size=0,blksize=16384 }) = 4295171888 (0x100031f30) > write(4,"From root@bristol.ac.uk Sun Jul "...,2041) = 4295172488 (0x100032188) > lseek(4,0x0,SEEK_SET) = 4295169848 (0x100031738) > fstat(4,{ mode=-rw------- ,inode=331538,size=2041,blksize=16384 }) = 4295171888 (0x100031f30) > read(4,"From root@bristol.ac.uk Sun Jul "...,16384) = 4295178608 (0x100033970) > close(4) = 4295170688 (0x100031a80) > unlink("/tmp/mutt-mech-cluster241-XSYQpzbj") = 4295170928 (0x100031b70) >> Is debugging turned on; was mutt built WITH_DEBUG=yes? > > yes, I just rebuilt with this set. Uh, I rather meant that debugging might cause unoptimized code, but given such repeated I/O to /tmp files I think that's more the culprit. Any of the patches causing it? Do you dare remount /tmp as asynchronous file system? I don't see fsync(), so async might help a bit, and is reasonable for /tmp. >> Can you verify the header cache databases, or move them away just for >> the sake of the experiment? > > sorry, I don't know what you mean here. You enabled header caches during the build, and if they were excessively large or broken, that might also cause slowdowns; but they need to be run-time configured, which you did not, so forget this. >> Does it help if you "make clean" before building world? This has cured >> strance effects on occasions in -STABLE (RELENG_[6-9]) branches for me. > > Well, I might do this later, if no other > clue emerges. Looking at the truss output, unless the 32nd bit set is required by the IA64 calling conventions, that may be necessary regardless of the mutt issue.