> Scenario:
> 1) runx -bpp 32 (KDE w. 4 terms active)
> 2) mount laptop (486/40+2.0.32) via knfs on 2.1.105 server, and start
> kernel build.
> 3) start 1gig tcp throughput test to laptop (repeat when finished)
> 4) start glibc build in server
> 5) start make -j bzImage on server (repeat when finished)
>
> All went well until 11:45 when I noticed that the glibc build and
> make -j bzImage weren't making any more progress, and X became VERY
> slow to respond. This kept getting worse as time went on. The kernel
> build from laptop kept running fine as did the tcp throughput test.
>
> I let it continue to grind until 13:30 before killing everything via
> an rlogin from the laptop. I then ran a Bonnie -s 100 to flush the
> system, and discovered that I had 64Mb still tied up afterward, whereas
> normally it's only 6-7Mb. I took it down to single user and repeated
> the Bonnie to no effect.
Hi Mike,
Glad to see you're up to your stress-testing again. I'm not aware of any memory leak problems in the
patches I've posted, but please do run the leak detector and report the findings.
> Jun 8 07:02:47 mikeg kernel: tcp_do_sendmsg: limiting extra 2700 to 846
> Jun 8 07:02:47 mikeg kernel: tcp_do_sendmsg: limiting extra 2700 to 846
> Jun 8 07:02:47 mikeg kernel: tcp_do_sendmsg: limiting extra 2596 to 742
These are just informative messages to show that the size-limiting code was triggered. By cutting back the
skb size, it avoids putting the socket over its memory limit, allowing for one more skb to be allocated
before having to wait for memory.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu