Modify the driver's interrupt routine to get the data, put it in a buffer,
and wake up a user level process when the buffer gets full, meanwhile
switching to a new buffer. I don't mean to be condescending, but this
is really basic producer/consumer type event gathering. Haven't you
ever done this before? I just assumed that anyone who has done kernel
performance work has had to gather event data from the kernel - how else
would you do it without completely disturbing other system activity?
Here's an analogy for you: what you've been suggesting over the last week
is quite similar to someone "discovering" that calling read(f,&c,1) in a
tight loop doesn't let you read I/O at 50MB/sec. Rather than reading up
on stdio or I/O buffering in general, this person gets all gung ho about
"fixing" the read() system call. I'm just trying to tell this someone
to go read about stdio - they'll be able to solve their problem without
"fixing" the system.
You could, of course, make an argument that reducing the cost of read()
is just a good thing, and I'd have to agree with that to a point.
But you could "fix" read() all you wanted, and you would still never
get performance as good as using stdio or some variant of stdio.
In your case, you are so fixated on this perceived problem that you
simply can't back up and realize that there are better approaches.
My advice is to think hard about the buffering scheme I suggested for
the driver and get on with your life. You'll be able to handle your
load on a 286, imagine!
-
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/