Re: computer becomes slow when compiling something

From: Jeff Roberson <jroberson_at_chesapeake.net>
Date: Tue, 28 Aug 2007 13:32:55 -0700 (PDT)
On Tue, 28 Aug 2007, Kostik Belousov wrote:

> On Tue, Aug 28, 2007 at 09:36:26AM -0500, Oleg Nauman wrote:
>> On Tue, Aug 28, 2007 at 12:48:13PM +0800, Ganbold wrote:
>>> Kostik Belousov wrote:
>>>> On Mon, Aug 27, 2007 at 11:14:58PM +0100, Robert Watson wrote:
>>>>
>>>>> On Mon, 27 Aug 2007, Ganbold wrote:
>>>>>
>>>>>
>>>>>> I'm running FreeBSD 7.0-CURRENT with SCHED_ULE, INVARIANTS, WITNESS
>>>>>> enabled kernel.
>>>>>>
>>>>> Try the same thing again without INVARIANTS and WITNESS, both of which
>>>>> can consume a lot of CPU in kernel on a very active system, especially if
>>>>> lots of vnodes are being allocated and freed.  Especially WITNESS.
>>>>>
>>>>
>>>> It does happens on the kernels without debug options, in particular,
>>>> WITNESS and INVARIANTS.
>>>>
>>>> It happens when a lot of short-lived processes are rapidly created.
>>>> Compilation is a good example of such workload; running configure script
>>>> is even better.
>>>>
>>>
>>> What would be a solution to this kind of problems?
>>
>>  From my point of view it exhibits some issues with standard SCHED_4BSD
>> scheduler in the 7.0 (my laptop is mostly unusable during 'make buildworld'
>> for example - keyboard exhibits lost event sometimes, sound is jerking etc etc).
>> So I'm switched to SHED_ULE on my UP laptop; it was helpful. I'm running
>> custom kernel without debug options though.
>
> SCHED_ULE also exhibit the behaviour, but in lesser degree. Due to this,
> I suspect that the problem in the common code.

make -j16 buildworld on my 1.6ghz Pentium M does not disturb firefox or 
other interactive tasks at all.  ULE has specific heuristics that penalize 
forking parents and return childrens interactivity history to them.  This 
seems to work fairly well in practice.

Looking through the other parts of this thread I see a mention of this 
problem being new between 6.2 and 7-CURRENT.  I wonder if it has anything 
to do with increasing costs of gcc?  It is often perceived as system 
slowdown when we upgrade gcc.  It likely consumes more memory than before 
as well.

The other likely culprit is some leftover giant code, especially the sound 
subsystem is subject to this I believe.

schedgraph (/usr/src/tools/sched/schedgraph.py) was created for exactly 
this purpose, although it only sometimes works on multiprocessor machines 
due to tsc synchronization issues.  It's worth trying however.  There are 
instructions at the top of the file for gathering traces.   You may send 
them to me if you'd like me to look at them.  Or you can do some digging 
and install py-tkinter yourself.

Thanks,
Jeff

>
> Jeff, any suggestions ?
>
Received on Tue Aug 28 2007 - 18:30:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC