Date: Mon, 13 May 2013 11:23:45 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Eugen-Andrei Gavriloaie <shiretu@gmail.com> Cc: freebsd-hackers@freebsd.org, Paul LeoNerd <leonerd@leonerd.org.uk> Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <CAJ-VmonjOS7Axq18VxL6B53T4DVgAYdY3LaT8nd7afFj2dq3cA@mail.gmail.com> In-Reply-To: <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com> References: <CCE4FFC4-F846-4F81-85EE-776B753C63C6@gmail.com> <20130513185357.1c552be5@shy.leonerd.org.uk> <CAJ-VmomQmPjtUhUo2%2BK=0Ychw-=qgawrZt3hnYeCPNNhA9T50A@mail.gmail.com> <CAJ-VmonKC_7J=aNgRntub9DN%2BEfQxrhMjstXHSJ634%2BaFemcLg@mail.gmail.com> <20130513191513.786f4f02@shy.leonerd.org.uk> <8A02C28F-89CB-4AE3-A91A-89565F041FDE@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just as a data point, I managed 50,000 + connections, at 5,000 + a second, doing a gigabit + of traffic, mid-2000s, with the userland management of all of the socket/disk FD stuff. The biggest overhead at the time was actually the read/write copyin/copyout, NOT the locking overhead of managing this stuff. Why? Because I architected the HTTP side of things to specifically pin FDs to threads, and not allow arbitrary threads to deal with arbitrary FDs. This removed the need for almost all of the state locking that people are concerned about here. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonjOS7Axq18VxL6B53T4DVgAYdY3LaT8nd7afFj2dq3cA>