Re: PREEMPT_RT and I-PIPE: the numbers, part 4

[Ingo Molnar <mingo@elte.hu>]

* Paul Rolland <rol@witbe.net> wrote:

> > "IRQ & hd" run:
> > Measurements   |   Vanilla   |  preempt_rt    |   ipipe
> > ---------------+-------------+----------------+-------------
> > fork           |     101us   |   94us (-7%)   |  103us (+2%)
> > open/close     |     2.9us   |  2.9us (~)     |  3.0us (+3%)
> > execve         |     366us   |  370us (+1%)   |  372us (+2%)
> > select 500fd   |    14.3us   | 18.1us (+27%)  | 14.5us (+1%)
> > mmap           |     794us   |  654us (+18%)  |  822us (+4%)
> 
>                                   ^^^^^^^^^^^^
> You mean -18%, not +18% I think.
> 
> Just having a quick long at the numbers, it seems that now the "weak" 
> part in PREEMPT_RT is the select 500fd test.
> 
> Ingo, any idea about this one ?

yeah. In the '500 fds select' benchmark workload do_select() does an 
extremely tight loop over a 500-entry table that does an fget(). fget() 
acquires/releases current->files->file_lock. So we get 1000 lock and 
unlock operations in this workload. It cannot be for free. In fact, look 
at how the various vanilla kernels compare:

    AVG           v2.6.12        v2.6.12-PREEMPT        v2.6.12-SMP         
 ------------------------------------------------------------------
       select:      11.48           12.35 (  7%)       26.40 (129%)

(tested on one of my single-processor testsystems.)

I.e. SMP locking is already 129% overhead, and CONFIG_PREEMPT (which 
just bumps the preempt count twice(!)) has 7% overhead. In that sense, 
the 27% select-500-fds overhead measured for PREEMPT_RT is more than 
acceptable.

anyway, these days apps that do select() over 500 fds are expected to 
perform bad no matter what locking method is used. [To fix this
particular overhead we could take the current->file_lock outside of the
loop and do a get_file() within do_select(). This would improve SMP too.
But i doubt anyone cares.]

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/