[openbeos] Re: Tracker Task Loop
- From: "Cyan" <cyanh256@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 18 May 2008 09:29:07 +0100 BST
> Could someone please tell me what I can do to keep Tracker Taskloop
> from spinning out of control and eating up tons of processor
> cycles? I can't figure out what makes it go crazy, but it can
> literally bring the system to its knees sometimes.
Tracker_taskloop finally started misbehaving again this evening
(50% CPU consumption on one core -- the normal failure mode), and
I had a chance to run the debugger on it.
My findings:
Inside StandAloneTaskLoop::Run(), the "tracker_taskloop" thread is
spinning in some kind of loop, containing calls to the following
functions (not listed in any particular order):
system_time()
snooze_until()
BLocker::Lock()
BLocker::Unlock()
BObjectList<BPrivate::DelayedTask>::CountItems()
ItemAt(long)
RunIfNeeded()
These are in addition to a number of < 0, >= 0, etc. tests.
There are no issues with acquiring the lock -- the spinning occurs
entirely in the thread function (StandAloneTaskLoop::Run()), calling
all of these functions each cycle.
These are the exact same functions which are called when
tracker_taskloop is operating normally, so it appears to be some
kind of polling thread. I have also seen it call RunWhenIdleTask()
under normal operation, but only once.
From this I would guess that the polling rate-throttle via snooze()
is failing, causing it to start consuming 50% of the CPU time under
some conditions.
(Failure does not appear to be related to system uptime, so it
probably isn't a bigtime_t casting issue).
Note: I'm using cpu_fix here. However, on systems without this
installed, snooze() might be failing completely, leading to a 100%
CPU utilization situation similar to what Dane was describing.
I'm not sure if this problem exists in current versions of Tracker,
and/or whether it also happens under Haiku. The very intermittent
nature of the problem makes this very difficult to answer unless the
system is used full-time.
As nobody has come forward confirming the presence or absence of this
issue in present-day Tracker, I'm assuming it may still be a valid
bug?
- Cyan
---
> I've had a similar issue here for years. It has never been much of
> a problem, because the thread priority is "low" (5) -- even on a
> single-processor machine this doesn't seem to impact system
> responsiveness. Killing Tracker and restarting it stops the spinning.
> It also seems to consume exactly 50% of one CPU, on both a
> single-processor Athlon (1.33GHz) and a quad-core Core2 (2.4GHz),
> which strikes me as very strange.
> The 'FileTypes' application reports OpenTracker as version 5.2.1
> -- it's quite old now, dated around Nov 2003 for all three files.
> This is running under R5+BONE.
> For some reason, it doesn't start spinning until quite some time
> after booting, sometimes many hours. Maybe it only starts spinning
> once something happens, such as performing a certain query, etc.,
> but I haven't managed to trace it to anything yet.
> One potential factor that could be involved is the number of files
> and/or partition size. I suspect in both of our cases we may have
> more files and/or larger partitions than the average BeOS/Haiku user.
> In this case, there's around one million files (which are queried
> several times a day), consuming about 150GB on several BFS
> partitions, one of which is over 200GB.
> Block size is 2K, and the recommended adjustments to the disk cache
> size (in the kernel settings file) have been made.
> Also, some of the folders contain an unusually large number of files,
> especially the dreaded 'Stuff' folder (over 1000 files).
> Tracker seems to struggle displaying this many items (they "pour"
> into the window over about 10+ seconds, like it's running inside
> a PC emulator on a NES), so maybe one of these could be a trigger.
> Also, I've noticed that occasionally some live queries will stop
> updating; maybe this could be related to the task loop getting
> locked up? It doesn't seem to impact anything else on the system
> though -- hard disk access is still very fast, so it probably isn't
> spinning inside a driver.
> I'll keep an eye on it today to see if I can trace it any further,
> assuming it starts (it hasn't started spinning yet).
> What does this thread actually do?
> - Cyan
----
> Could someone please tell me what I can do to keep Tracker Taskloop
> from
> spinning out of control and eating up tons of processor cycles? I
> can't
> figure out what makes it go crazy, but it can literally bring the
> system
> to its knees sometimes. If I use Processcontroller to kill the
> taskloop, things get nice again right away...and the odd part is that
> killing taskloop never seems to hurt anything. But that's using a
> pail
> to fix a leaky roof. I need to figure out what's causing it, or at a
> bare minimum, find a way to keep auto-killing the thing.
>
> Suggestions?
>
> Dane
>
Other related posts:
