bug-hurd
[Top][All Lists]
Advanced

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

Re: Degradation of GNU/Hurd ``system performance''


From: Sergio López
Subject: Re: Degradation of GNU/Hurd ``system performance''
Date: Thu, 22 Sep 2011 17:40:01 +0200

2011/9/22 Svante Signell <svante.signell@telia.com>:
> On Thu, 2011-09-22 at 04:45 +0200, olafBuddenhagen@gmx.net wrote:
>> Hi,
>>
>> On Mon, Sep 05, 2011 at 06:42:22AM +0200, olafBuddenhagen@gmx.net wrote:
>>
>> > As recently I aquired the (bad) habit of running my system 24/7,
>> > almost never voluntarily rebooting, I was able to make further
>> > observations.
>>
>> I totally forgot to mention another important bit: the growing swap
>> consumption can be triggered "reliably" simply by installing a lot of
>> Debian packages -- doing an "apt-get upgrade" for example. (I
>> occasionally observed growing memory usage with other commands doing I/O
>> on large amounts of data as well; but couldn't pinpoint any specific
>> situations so far... Perhaps it's just some randomly triggered bug
>> accumulating dead objects in memory or something like that?)
>
> Regarding memory usage, when building packages that hangs/are
> interrupted many processes are not terminated and I
> see /usr/bin/faked-tcp and hurd/fifo instances still in the process
> list. Are there timeouts for dead processes?

This problem could be related with a bug I've noticed some days ago.
If a user task is interrupted while doing an RPC to a translator while
the latter is doing a vm_copy, the translator (and all tasks waiting
for a response from it) gets stuck. An easy way to reproduce this, is
sending a SIGINT in the middle of an opertation like "dd if=/dev/zero
of=test.bin bs=1M count=100".

I think threads running vm_fault_copy doesn't deal properly with
thread_abort, but I didn't have time to check it.



reply via email to

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