Re: "swiN: clock sio" process taking 75% CPU
I wrote:
> About 6 minutes after booting (on two occasions; I don't
> guarantee that this doesn't vary), a process that appears
> in the output of "ps" as "[swi4: clock sio]" begins to
> use about 3/4 of the machine's CPU. I think it does so
> more or less instantaneously. It continues to do so
> indefinitely, so far as I can tell.
So, here's the answer. Whether it's the same thing that's
afflicted the other people who've reported similar problems,
I don't know. (Thanks to John Baldwin on -hackers for
pointing me in a useful direction.)
Executive summary: If you see symptoms like the one above,
are you running a syscons screen saver? (To check: run
"kldstat | grep _saver".) If so, turn it off and the problem
may go away.
1. The machine in question runs largely unattended.
2. I'd enabled the syscons screen saver and chosen one
of the ones that puts the screen into a graphics mode.
("warp", as it happens; "fire" behaves similarly;
the character-mode ones don't; I haven't looked at
all of them.)
3. The screen saver kicks in 5 minutes after it gets
turned on in /etc/rc.d/syscons, provided nothing's
happening on the console. Which it isn't: see #1.
4. Now, how do those graphics-mode screen savers work?
They write to the video card's frame buffer directly,
but there's only a 64k block of RAM they can do this
through. So, to cope with larger screens, there's a
bank switching facility accessed by a BIOS call.
5. This BIOS call, on my machine, takes about 0.1ms; you
need to do two of them for a bank switch, so the time
actually taken is about 0.2ms.
6. The screen savers are written in a less than optimal way,
and do that bank switching thing many times. For instance,
the "fire" screen saver does it at least once for every
screen line. Even when the entire screen actually fits
into a single bank so that no switching at all should be
needed.
7. So the screensaver eats up something on the order of half
my CPU time; the exact figure depends on which screensaver
and on more exact timings than I've given above, which is
how it ends up actually being 75% for the "warp" screensaver.
8. The screensaver gets run in callouts from a kernel
interrupt thread that happens to have a silly name
like "swi4: clock sio".
This is eminently fixable, in several different ways. I've
offered to prepare a patch, or perhaps someone else will
do so, so there's a reasonable prospect of later versions
of FreeBSD not having this problem. For the time being,
there's a simple workaround for anyone facing the same
problem I did: *turn off the screensaver*, or replace it
with one that doesn't use a graphics mode.
For clarity: this is a problem with (some) FreeBSD syscons
screen savers, the ones you might enable in /etc/rc.conf;
not with the ones like xscreensaver that you might run in
user mode under X.
--
g
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "swiN: clock sio" process taking 75% CPU
I wrote: > About 6 minutes after booting (on two occasions; I don't > guarantee that this doesn't vary), a process that appears > in the output of "ps" as "[swi4: clock sio]" begins to > use about 3/4 of the machine's CPU. I think it does so > more or less instantaneously. It continues to do so > indefinitely, so far as I can tell. [etc] No ideas? I'm willing to help track this down, and the machine in question is sufficiently little used that I can do so without gross inconvenience; but I don't have enough FreeBSD kernel expertise to feel like diving in blind. * A little more information, in case it's useful to anyone: | $ echo; sysctl debug | egrep to_ | debug.to_avg_mpcalls: 2890 | debug.to_avg_mtxcalls: 0 | debug.to_avg_gcalls: 768 | debug.to_avg_depth: 3815 That's with HZ = 100. Here are some numbers from a message in freebsd-ia64, from Marcel Moolenaar, in 2004-07, to someone seeing symptoms like mine. They're meant to be typical healthy numbers. Mine above look somewhat worse, but not insanely so; surely not enough to explain the difference between using 0.3% cpu and using 75%. Marcel also had HZ=100. | % sysctl debug | grep to_avg | debug.to_avg_depth: 2500 | debug.to_avg_gcalls: 1003 | debug.to_avg_mpcalls: 1255 * It would be a shame if the only conclusion to be drawn from this were "sometimes a machine running FreeBSD is just 4x slower than it should be, and no one knows why". -- g ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "swiN: clock sio" process taking 75% CPU
I wrote, inter alia, > About 6 minutes after booting (on two occasions; I don't > guarantee that this doesn't vary), a process that appears > in the output of "ps" as "[swi4: clock sio]" begins to > use about 3/4 of the machine's CPU. I think it does so > more or less instantaneously. It continues to do so > indefinitely, so far as I can tell. David Wolfskill e-mailed me off-list to suggest looking at the output of "vmstat -i". Answer: the interrupt rates all appear to be normal, or at least similar to those he observes on his machines which don't exhibit my problem. More specifically ... -- excerpt from my reply to David begins -- I get this: | interrupt total rate | irq1: atkbd0 3 0 | irq6: fdc010 0 | irq14: ata0 2913 1 | irq15: ata1 47 0 | irq17: xl0 7342 4 | cpu0: timer 302649199 | Total 312964206 (so the rate of timer interrupts doesn't appear to be insane) and | 7:56PM up 26 mins, 1 user, load averages: 1.87, 1.45, 1.08 (so the cost in CPU cycles of servicing them -- if that's what the rogue process is doing, which seems somewhat plausible -- *does* appear to be insane). -- excerpt from my reply to David ends -- -- g ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"swiN: clock sio" process taking 75% CPU
ecounters tick every 10.000 msec ad0: 38166MB at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a -- dmesg output ends -- I would be grateful for any insight into what's going wrong and how (if at all) it can be fixed or worked around. I'm not subscribed to -questions or to -stable, so would prefer to be cc'ed, but I'll check the web archives and should therefore see any responses that go only to the list(s). Thanks in advance! -- Gareth McCaughan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DVD writer support in -STABLE?
I'm thinking about getting a DVD writer as a backup device for use with my -STABLE system. It's not clear to me what level of support there is for this in -STABLE. 1. If I just want to treat a DVD as an unusually large CD, will that "just work"? I mean, can I build a 4GB ISO9660 filesystem using "mkisofs" and then write it to DVD using "burncd"? The documentation for "mkisofs" implies that arbitrarily large filesystems are possible, but neither the manpage nor the source for "burncd" says that anything other than plain ol' CDs are supported. 2. What's the state of UFS support, if any? Should I care? 3. Can I assume safely that any DVD writer that claims ATAPI compliance can be used happily with -STABLE? If not: the particular device I'm currently looking at is the Pioneer DVR-A04. It's a DVD-R/W drive; the manufacturer's web page says its interface is "ATAPI (ATA/ATAPI-5 & MCC3, SFFCINF 8090 Ver.5)". Thanks in advance for any replies. I'll be checking the list, but copies to me would be helpful as I'm not actually subscribed. (I already tried asking on -questions, by the way. No reponse.) -- g To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
