Messages in this thread |  | | Date | Tue, 24 Oct 2000 03:58:37 +0200 | From | Andi Kleen <> |
| |
On Mon, Oct 23, 2000 at 06:42:39PM -0700, Linus Torvalds wrote: > > > On Tue, 24 Oct 2000, Andi Kleen wrote: > > > > Also with the poll table mmap'ed via /dev/poll and the optimizations I > > described poll could be made quite nice (I know that queued SIGIO exists, > > but it has its drawbacks too and often you need to fallback to poll anyways) > > The problem is that your proposed optimizations would be horrible: the > poll events themselves happen when some other process is running, so you'd > have to do some serious VM hacking and consider the poll table to be some > kind of direct-IO thing etc. Ugh.
I don't see the problem. You have the poll table allocated in the kernel, the drivers directly change it and the user mmaps it (I was not proposing to let poll make a kiobuf out of the passed array)
> > And the file->fd mapping is not a simple mapping, it'a s 1:m mapping from > file -> potentially many [process,fd] pairs.
Yes, but in 95% of all cases it is a 1:1 mapping, so you could just fall back to the old slow method when that isn't the case. > > Doing the caching across multiple poll-calls is even worse, you'd have to > cache where in user space people had the array etc. Not pretty.
The file -> fdnum reverse table does not depend On every poll call you can walk the poll table and fix the pointer from file to poll entry. That can be done cheaply during copyin for normal poll. mmap'ed /dev/poll could probably use a lazy method (cache the pointers and verify and walk if it the verify fails)
> I'm sure it can be speeded up, I'm just not sure it's really worth it if > you'd instead just have a better interface that wouldn't need this crap, > and consider poll() as just a compatibility layer.
What is your favourite interface then ? ndi /dev/poll is nice in that it can be relatively easy hacked into older programs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |