[lkml]   [2001]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] /dev/epoll update ...
Davide Libenzi wrote:
> > Well, memory move consists of 2 words: (a) file descriptor; (b) poll
> > state/edge flags.
> 2-words * number-of-ready-fds == pretty-high-cache-drain

Perhaps there is a cache issue, but note it is the number of _new_ ready
fds (since the last sample), not the number currently ready.

> > That will be completely swamped by the system calls and so on needed to
> > processes each of the file descriptors. I.e. no scalability problem here.
> The other issue is that by keeping infos in file* you'll have to scan each fd
> to report the ready ones, that will make the method to fall back in O(n).

No, that would be silly. You would queue signals exactly as they are
queued now (but collapsing multiple signals per fd into one).

> Anyway there's a pretty good patch ( ),
> that has been tested here :
> that implement the signal-per-fd mechanism and it achieves a very good
> scalability too.

It has the bonus of requiring no userspace changes too. Lovely!

-- Jamie

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.077 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site