lkml.org 
[lkml]   [1998]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bug in 2.1.89 include/net/sock.h?


On Sun, 22 Mar 1998, David S. Miller wrote:
>
> Ok. In this case I propose:

No, don't do it this way.

> 1) resource allocation charging is done the same as now
> 2) a mechanism is added to tell sock_[rw]free() to not make
> the "space available" wakeup callbacks, perhaps a sort
> of skb_nowakeup() which sets state in the skb, after memory
> and SOCK linkage has been made, which makes this happen
> and we use this in TCP for ACK frames, and transmission clones

If ACK's etc frames take up resources, we _have_ to wake up, because
otherwise we can have cases where we never wake up when the resources are
free'd.

Please do NOT add any silly special cases for wakeup: either you
shouldn't account for the ACK's per-socket, or you have to wake things up
regardless of whether it is an ACK or a normal packet.

Doing a special "tcp_nowakeup()" thing is only digging yourself into a
deeper hole and will be truly horrible to debug.

Note that regardless of whether the free'd frame was a ACK or a data
frame, you don't actually have to wake up things unconditionally. Right
now we are using the stupid approach that we _always_ wake up, but that is
obviously bad regardless of whether the packet was an ACK or not.

Something like

/* Wake up only if we have more than half the wspace free: */
if (atomic_read(sk->wmem_alloc)*2 <= sk->sndbuf)) {
... wake_up() ..
}

should get rid of some unnecessary wake-ups, whether they are due to ACK's
or not. There's no point in having the writer trickle the write data in
small chunks anyway.

> 3) we investigate wake up policies past these changes at some
> later data, ie. research problem ;-)

Not together with 1+2 which would be a potentially endless source of
hard-to-find bugs. David, I do _not_ want people to start adding more
causes for bugs for no better reason that some fairly minor performance
tweak that probably has other much better solutions anyway.

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.075 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site