Re: FreeBSD's problems as seen by the BSDForen.de community

Dominic Fandrey wrote:
> Kris Kennaway wrote:
>> Kris Kennaway wrote:
>>> Dominic Fandrey wrote:
>>>> The first problem is the unbearable performance many AMD users are
>>>> suffering
>>>> for several chipset and CPU generations. Even minimal I/O load on a
>>>> hard disk
>>>> suffices to lock up whole systems. Posts on the mailinglists current and
>>>> stable have often been answered with denial or have simply been
>>>> ignored. Only
>>>> on very rare occasions (if at all) have these problems been taken
>>>> seriously.
>>> Thanks for the feedback.  It is hard to respond to the reports of poor
>>> performance or other problems without specific information though.
>> FYI this was not a dismissal, it was an invitation for you to follow up
>> with the specific problems your members have seen so we can try to
>> evaluate them.
> 
> Yes, thank you. I consider the first replies to the mail as very positive and
> the intention to take us serious and try help us is clear. I'm a bit
> disappointed the thread has been hijacked by people who want to press their
> own agenda. The last time I sent a performance complaint to ports_at_ it resulted
> in faster code (pkg_install, bsd.ports.mkd), not in license discussions.
> 
> Anyway, the general description is the following: during a portupgrade the
> system response time goes up to several seconds or even minutes during a
> portupgrade. Imagine writing an email and having to wait a minute for your
> typing to show up. Needless to say, that using a mouse is impossible.
> This effect how ever is, though best seen there, not limited to X. Ping times
> to an affected system doing a portupgrade also go up to several seconds (over
> a cross cable).
> 
> What I need now is someone to tell me, what to do in order to track the
> reasons down. It has recently been brought to my attention that there is a
> tool for creating scheduler traces, which I might ask people to collect, but
> my unqualified opinion is that it's an interrupt handling problem.

Yes, it could be.  What do vmstat, vmstat -i and top -S say?  In the 
latter, look at which threads are using CPU.

Kris