Re: [PATCH] [RFC] Optimize select/poll by putting small data sets on the stack

From: Andi Kleen
Date: Tue Jan 03 2006 - 18:04:00 EST


On Tuesday 03 January 2006 23:14, Eric Dumazet wrote:
> Andi Kleen a écrit :
> > This is a RFC for now. I would be interested in testing
> > feedback. Patch is for 2.6.15.
> >
> > Optimize select and poll by a using stack space for small fd sets
> >
> > This brings back an old optimization from Linux 2.0. Using
> > the stack is faster than kmalloc. On a Intel P4 system
> > it speeds up a select of a single pty fd by about 13%
> > (~4000 cycles -> ~3500)
>
> Was this result on UP or SMP kernel ? Preempt or not ?

SMP kernel, non preempt, on a uniprocessor hyperthreaded CPU.

>
> I think we might play in do_pollfd() and use fget_light()/fput_light()
> instead of fget()/fput() that are somewhat expensive because of atomic
> inc/dec on SMP.

One idea was to just cache the file references over multiple syscalls and only
free them using a timer or when some thread calls close().
This would also avoid taking the spinlocks to set up the wait queues.

Then a new select or poll would just check if the input set matches
the caches and only fix up what changed.

But i didn't implement this because I would be quite a bit more complicated
instead of this simple patch.

>
> (I believe that select()/poll() based daemons are mostly non
> multi-threaded, since high performance multi-threaded programs should be
> using epoll...)

Yes, epoll should have a similar effect.

-Andi

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