Re: BitTorrent+Reiser4: curiouser and curiouser

[Alexander Zarochentsev <zam@namesys.com>]

Hi,

On 22 September 2006 10:28, David Masover wrote:
> Azureus had a problem.  Once it got up to a good clip downloading, it
> would thrash the disk.  It would thrash the disk, and the system, so
> hard that even web browsing was difficult, due to disk access being
> many, many times slower than Internet access, even an Internet which
> is being hogged by BitTorrent.
>
> After changing Azureus' cache to 32 megs, and telling it not to write
> files immediately, I thought I had the problem solved -- no thrashing
> at all.  Until the cache got full.  Then:  Thrashing.  Less freqent,
> but much more vigorous -- Azureus becomes extremely unresponsive for
> a few minutes.
>
> It shouldn't be touching the disk AT ALL when there's over a gig of
> FREE RAM (as in, neither buffer nor cache nor actually used yet), and
> the file I'm attempting to download is less than 200 megs.  I tried
> an strace, but as I am not at all skilled in the ways of debugging or
> reverse engineering, I got syscall spam -- a 200 meg log file, and
> when I finally found a decent way to analyze it, I found most of
> Azureus' system call wall time is spent in futex().  Huh?

I guess futex (, FUTEX_WAIT, ) calls can be ignored in this analysis. 
They just wait another threat to call futex(, FUTEX_WAKE, ).  
Interesting to find that thread and look what it was doing before 
FUTEX_WAKE? Or FUTEX_WAIT returns ETIMEDOUT?

> Looked up "futex" on Wikipedia, and I still have no clue how this
> makes any sense.  Either futex was somehow thrashing the disk, or
> Azureus has somehow managed to fork completely out of strace's
> control.  Or maybe it's somehow something that the kernel is doing on
> its own, which is somehow forcing azureus to block, but somehow not
> tripping strace's timers while doing so.
>

[ ... ]

-- 
Alex.