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

[Bruce Dawson]

I'll give those a try.

BTW, I just posted the blog post to share what I'd found. You can see it
here:

http://randomascii.wordpress.com/2013/03/18/counting-to-ten-on-linux/

I hope it's accurate, and I do think it would be worth mentioning the issue
in the documentation for 'time' and the bash 'time' internal command.

-----Original Message-----
From: Linda Walsh [mailto:bash@tlinx.org] 
Sent: Monday, March 18, 2013 7:15 PM
To: Bruce Dawson
Cc: bug-bash@gnu.org; bash@packages.debian.org
Subject: Re: Bug/limitation in 'time' (kernel setings?)...



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...