pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: freeze, high CPU getting new headers


From: Duncan
Subject: [Pan-users] Re: freeze, high CPU getting new headers
Date: Wed, 6 Aug 2008 23:30:56 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies)

walt <address@hidden> posted
address@hidden, excerpted below, on  Wed, 06 Aug 2008 18:59:41
+0000:

> I must admit that David's gdb trace does look like a program that's at
> least doing a good imitation of useful work, but there's no way to know
> how fast pan is doing it.  His trace does mention values being optimized
> out, so I wonder if this problem has something to do with the compiler
> flags used during compilation.  Dunno, but gcc-64 might have issues
> there that gcc-32 doesn't.

FWIW, here's my CFLAGS, CXXFLAGS, and LDFLAGS:

CFLAGS="-march=k8 -pipe -msse3 -O2 -frename-registers -fweb -fmerge-all-
constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize -
fdirectives-only -freorder-blocks-and-partition -combine"

CXXFLAGS="-march=k8 -pipe -msse3 -O2 -frename-registers -fweb -fmerge-all-
constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize -
fdirectives-only"

LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common"

That's what my entire system is compiled with, except the packages where 
Gentoo has found one that doesn't work and replaced or downgraded 
strength as part of their ebuild scripts.  (BTW, man gcc is quite 
informative on C(XX)FLAGS, and seems to be getting even more so with each 
gcc release.  I've not found a similar doc for LDFLAGS, unfortunately, so 
have just picked them up as I found them.)

I agree on the iffiness of the X thing, but I don't have a better 
explanation, unless perhaps it /is/ X but X updating is stalled waiting 
for pan to process a callback or some such, and pan's too busy to notice.

One thing tho, it's sure using that fd, whether it's a regular file or a 
socket or whatever, for both input and output during this period.  That's 
actually one of the reasons I think it's a socket, as I don't expect both 
input and output like that to a regular file is very common.

Two things would be nice.  1) Timestamps on either/both the strace and 
the gdb, do either of them support that?  Then we could see how long it's 
spending on the poll before returning, for instance.  2)  Is there a way 
to query the system for the path of a fd from another process (with 
sufficient privs, of course, to prevent cross-user leaks)?  It'd sure be 
nice to find out what that fd it's cycling on is, for sure.  Of course, 
one could get it if they traced pan from startup, but that'd be a HUGE 
trace to worth thru by the time it hung.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]