From: "" <pmarques@grupopie.com>
To: Neil <neil@qlsc.sdu.edu.cn>
Cc: "" <linux-kernel@vger.kernel.org>
Subject: Re: Yet another I/O modeling
Date: Sun, 27 Feb 2005 23:36:40 +0000 [thread overview]
Message-ID: <1109547400.42225988b8070@webmail.grupopie.com> (raw)
In-Reply-To: <422219ED.5060404@qlsc.sdu.edu.cn>
Quoting Neil <neil@qlsc.sdu.edu.cn>:
> hi,all
> select/poll I/O modeling is fast,easy to use,it returns the number of fd
> which are acitvity,but you should scan the fd array to find which fd is
> ready,it costs a lot of time on a heavy load server.
>
> I proposal another I/O modeling,named eselect.
> struct eselect_struct{
> unsigned long readbitmap[MAXBITMAPFD];//suppose the MAXBITMAPFD is
> MAX OPEN //FD NUMBER PER PROCESS
> int ret;//-1 on error,non-negative return value is the number of
> //acitvity fds
> }
> we can use __set_bit(),__clear_bit(),__find_first_bit()....functions to
> maintain the bitmap.
> So,you shouldnt scan the fd array any more.
I really don't see why __find_first_bit() is better than "scan the fd array".
They both seem like O(N) operations. You might be dividing the tests by 32 (or
64) but in a busy server with 3000 open sockets, what you really want is no
scanning at all.
Anyway, your problem is already solved. You should check epoll:
http://epoll.hackerdojo.com/
It's been in the kernel for a while, now (with CONFIG_EPOLL=y).
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
prev parent reply other threads:[~2005-02-28 0:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-27 19:05 Neil
2005-02-27 23:36 ` pmarques [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1109547400.42225988b8070@webmail.grupopie.com \
--to=pmarques@grupopie.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neil@qlsc.sdu.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®