bug-bash
[Top][All Lists]
Advanced

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

Re: Bug/limitation in 'time' (kernel setings?)...


From: Linda Walsh
Subject: Re: Bug/limitation in 'time' (kernel setings?)...
Date: Mon, 18 Mar 2013 19:14:36 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666


Bruce Dawson wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='$
> uname output: Linux Ubuntu1m 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5
> 18:04:39 UTC 2012 i686 i686 i$
> Machine Type: i686-pc-linux-gnu
> 
> Bash Version: 4.2
> Patch Level: 24
> Release Status: release
> 
> Description:
>         The basic problem is that if you time an operation that starts lots
> of sub processes - an operation whose execution is dominated by starting
> short-lived subprocesses - then time does not accurately record CPU time. In
> fact it is off by a lot. It reports the system as being about 75% idle when
> the task is entirely CPU bound. I've verified that the task is CPU bound by
> using iostat, mpstat, perf, and a few other programs.
----
        BTW,

        a few things you didn't mention, your kernel version,

        What scheduler your kernel is using...

        Also the settings of TICK_CPUACCOUNTING vs. IRQ_TIME_ACCOUNTING from 
your
        '/prog/config.gz' might be interesting...

        Those have to do  with cpu accounting and the default is 'simple tick 
based
cputime accounting',
        Vs. a non-default of 'fine granularity task level IRQ accounting.

        The latter might give you more accurate timing info for your tests, but 
really
have no clue .. just something to try, I suppose.

        Also the setting of your HZ/clock value...
        HZ_100/HZ_250/HZ_1000 (1/X for /second tick granularity).

        Do you have 'NO_HZ' set, HIGH_RES_TIMERS?

        Also important -- how your kernel is compiled:
        PREEMPT_NONE, PREEMPT_VOLUNTARY, or PREEMPT

        I'm not sure, how the RCU settings figure in but there's settings there 
that sound
like it might affect how fast you get rescheduled like 'Accelerate last
non-dyntick-idle CPU grace period
(RCU_FAST_NO_HZ), and RCU_BOOST.

        None of that, of course is BASH related, but it might very well affect 
your
issue, if you
wanted to try different kernel options.  No guarantee that any would affect it
either ... but
thought  I'd mention some settings I thought that might affect it.  EVen the
power level settings
of your machine -- power savings, vs. on-demand, vs. maxperformance...

        It sounds like the ACCOUNTING thing might be most pertinent, but 
thought I'd
throw in the
others just to be thorough...







reply via email to

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