>uaccess routines themselves. It is easy solution, yes, but will put a lot of
>bloat into the kernel. It is common to do several copy_from_user or to_user
According to me is _far_ better to bloat a bit the binary image then the
sources with not obvious unlock_kernel(). And btw the bloat will be SMP
only. I repeat again that unlock_kernel() will break changing the caller
so you'll find yourself doing:
[..]
unlock_kernel();
unlock_kernel();
[..]
xor you'll be a _no-op_.
When kernel_flag and ->lock_depth will be killed it will be _trivial_ to
kill my additional lines from uaccess.h.
BTW, I can also trivially remove the code bloat by doing the
spin_lock/unlock(&kernel_flag) in two EXPORTED function called in the slow
path (so we'll only check lock_depth/old in the inlince code), but I
didn't considered it as a major issue. I can agree completly in this
approch though. Let me know if you would like to see such
not-inline-in-slow-path code.
Until we'll have kernel_flag and ->lock_depth compiled in the kenrel my
code will continue to make sense.
If my *_kernel_lock_and_schedule() calls will decrease global performances
then it will be trivial to remove them at any time.
I strongly diagree with patches that unlock_kernel() all over the place.
If something has to be done we should start using finegrined spinlocks
instead of the kernel_flag. Such unlock_kernel() are going to break
tomorrow when I'll change the caller. That's really a _dirty-hack_. My
code instead will _never_ break and will continue to make sense as far as
the big kernel lock will exists.
So if we want to scale better in the middle of the copy_from/to_user (we
can) even if we are not yet finegrined enough, the only rasonable solution
is my one according to me.
>and so you would not have to go back and forth with acquiring/releasing
>kernel master lock.
I think getname is a minor issue. The problem is
ext2_file_write/file_read_actor, and other in-core places.
Andrea Arcangeli
-
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/