My, my. I'm so sure you're right but you don't mind if I look at it for
a minute do you?
: What Richard described *isn't* data GATHERING. Its data-based
: manipulation of a device. You can't buffer the incoming data because
: you need to use the incoming data and within 50us emit some new data
: (based on the input) to the device. This isn't an example where you
: can buffer up a certain amount of information, and then at the right
: time do something with it.
If you had read a few messages down, you would have seen where I said
"put the computation in the driver as well".
The counter to that is "we don't want to". Which is weak. Suppose that
you had a system that was capable of sustaining an interrupt rate of
X/sec. You needed to process events at Y/second where Y was slightly
less than X. You could imagine a set of values for Y where it just
simply wasn't an option to process this data at user level unless you
could transition to user level for free. At that point, you're doing
it in the driver because you have no choice. Right?
How about we break down the costs each way and see what makes sense and
what doesn't?
Breakdown of costs
I Interrupt
C1 Context switch to user process
S1 system call to get the data from device
P processing time
S2 system call to write some data to the device
C2 Context switch to some other process
On Mr Gooch's old 386's, my guess is the numbers are something like
I 10 usecs
C1 13 usecs
S1 4 usecs
P unknown, let's call it 5 usecs
S2 4 usecs
C2 10 usecs
Total 46 usecs
OK, that gives us a maximum event rate of 21K events/second assuming that
he does exactly 2 system calls per event (which I'll bet isn't true).
However, as Mr Gooch has repeatedly pointed out, he wants to do other work
on that system so chop off whatever you think he's going to need for that.
Now let's consider the in driver approach:
Breakdown of costs
I same, 10
P same, 5
Total 15 usecs
Gives us an event rate of 3x as fast. With none of the worries that Mr
Gooch has with respect to the run queues et al.
You tell me what you would do.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/