2 solutions
-----------
1. An obvious thing is to make the N-byte accesses (where N is a small
fixed value) inline without unlocking, and the variable-size accesses
out of line with unlocking.
In general the variable-size accesses copy more data than the fixed size
ones, so the out of line overhead isn't so significant there.
2. Another possibility is to handle this in the lock contention
handler -- thereby avoiding bloating the actual copying code.
I mean by checking EIP just as the fault handlers do.
I haven't thought of a good way to do this, but maybe it is possible.
> Also the unlock_kernel thing is not the right 2.3 fix - there the code should
> be fixed to have fine grained locks - but just a bandaid to fix the worst
> scaling problems in 2.2 with minimal changes.
Generally agree. The kernel lock shouldn't be held during whole long
sections of code that do multiple user space copies. So for example
code that does a series of user space copies, maybe with error checking,
should drop the lock once and reacquire it at the end (maybe). Andreas'
approach does more work than required in these cases. Though it is
clean to apply now, and it might be a good idea for debugging.
have nice day,
-- Jamie
-
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/