On Sat, Oct 17, 1998 at 05:42:45PM +0200, [EMAIL PROTECTED] wrote:
> Why our lock_sock does work in this way?
> Look: syncronize_bh() is necessary only in normal thread
> to wait until bhs will finish with THIS socket.
> Effectively, it can be replaced with waiting until ONLY THIS
> sk->sock_readers==1, right?
> Well, provided we add couple of atomic_inc(&sk->sock_readers) to bh tcp code,
> which is very easy.
>
> Please, tell me if I am wrong, probably, it is a hole in my brains.
Yes, I proposed to use a spinlock for this a few months ago. Unfortunately
I still don't have a SMP machine so I never implemented/tested. I believe
it would make TCP scale a lot better. The only questionable bit is the
asynchronous *_err ICMP handling, but even now it isn't completely safe
- and ICMP is unreliable anyways...
Regarding sock_readers - TCP bh should always lock_sock before doing anything
with a socket, with the only exception of one dubious case in tcp_v[46]_err().
Do you know of more?
>
>
> Another question is in queue 8) Have we something sort of
> spinlock_save_bh(spinlock)? I.e. thing, which translates to
> start_bh_atomic() on UP, and to spinlock, combined with
> cpu local bh protection. The last one is only to prevent dead loops,
> it does not assert any protection (but spinlock) and does not
> require any synchronization. This thing would be superb replacement
> for SOCKHASH_LOCK() and to bh_atomic() in ip_route_output()
> and in lots of another places, where spinlock_save_irq() is too strong
> and start_bh_atomic() is too expensive.
>
> Again, tell me if I am wrong, probably, it is another hole in my brains.
I agree that it is a good idea. I think Linux doesn't have it because
it smells to much like spls, which Linus has a religious dislike against ;)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
