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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
