* Paul Rolland <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
