Messages in this thread | | | Date | Sat, 9 Jul 2005 17:22:07 +0200 | From | Ingo Molnar <> | Subject | Re: PREEMPT_RT and I-PIPE: the numbers, part 4 |
| |
* 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/
| |