On Thu, 27 Jan 2000, David S. Miller wrote:
>Actually there is one place which cannot fail, allocation of the
>final FIN frame in TCP. It may never fail, it will loop until
>it gets the memory.
So just move the sched_yield loop into the caller just like getblk just
does so the problem will become local to TCP.
--- 2.2.15pre4/net/ipv4/tcp_output.c.~1~ Tue Jan 25 15:40:06 2000
+++ 2.2.15pre4/net/ipv4/tcp_output.c Fri Jan 28 10:27:13 2000
@@ -753,12 +753,16 @@
}
} else {
/* Socket is locked, keep trying until memory is available. */
- do {
+ for (;;) {
skb = sock_wmalloc(sk,
(MAX_HEADER +
sk->prot->max_header),
1, GFP_KERNEL);
- } while (skb == NULL);
+ if (skb)
+ break;
+ current->policy |= SCHED_YIELD;
+ schedule();
+ }
/* Reserve space for headers and prepare control bits. */
skb_reserve(skb, MAX_HEADER + sk->prot->max_header);
>Andrea, please find another way.
Well, the other way is trivial :)
--- 2.2.15pre4/mm/page_alloc.c.~1~ Tue Jan 25 15:40:06 2000
+++ 2.2.15pre4/mm/page_alloc.c Fri Jan 28 10:29:15 2000
@@ -242,6 +242,7 @@
* waiting for us we need to allow it to run a bit.
*/
if (gfp_mask & __GFP_WAIT) {
+ current->state = TASK_RUNNING;
current->policy |= SCHED_YIELD;
schedule();
}
But I'd prefer to get rid of such schedule completly in the MM since it is
going to harm the good citizens.
comments?
Andrea
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:20 EST