> Probably not. Although I did change it back but then change it in
> another way. Use the attached patch to back out those changes and let
> me know if it works (for some reason, I doubt it).
Let's see if I'm understanding things here. You made the looping change
because of the userfragsize change, correct? The idea being if
userfragsize is larger than the hardware's fragsize, we have to wait
longer to wake up.
Except poll_wait doesn't seem designed to be called this way, at a
glance. (Maybe it's possible to muck around with the poll table and call
again, as a hack? but this seems ugly, have to be very careful that
calling poll_wait twice doesn't corrupt memory, though, as implied in
some of the notes on http://linux24.sourceforge.net/)
fs/select.c:do_poll() calls schedule_timeout() after all do_pollfd's
have returned empty sets and there is still time remaining. so if you
just eliminate the loop in i810_poll, it will loop back and if there's
data available, poll(2) would return properly, but with extra latency. i
assume sys_select behaves the same way...
so, 2 choices to eliminate latency, either hack i810_poll further, or be
a lot more intelligent about calling wake_up. am i wrong?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/