linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] NFS Server performance and 8139too
@ 2001-05-13  7:32 Oleg Makarenko
  2001-05-13 10:53 ` netif_wake_queue wrong was " Andi Kleen
  0 siblings, 1 reply; 3+ messages in thread
From: Oleg Makarenko @ 2001-05-13  7:32 UTC (permalink / raw)
  To: linux-kernel; +Cc: ipv4

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]


Since 2.2.19 I have a very poor NFS server performance on Linux 
using 8139too driver (v0.9.14) while the driver v0.9.10 from 2.2.18 
works fine (even with 2.2.19)

I have checked 2.2.20pre2 and 8139too project pages and found no patches
for the problem. Am I alone with that bad NFS performance here?

My setup:

PII-500, 196M, Linux 2.2.19. rh6.2, 8139too, 
serves as NFS server and client for SCO OpenServer and file server and
client
for macintosh

the following command on SCO:

sco# cat /mnt/linux/one-megabyte-file > /dev/null 

takes about 30 minutes with 2.2.19 kernel and about 0.3 secs on 2.2.18.
(I have never made the real benchmarks, numbers are just to show the 
difference)

The following one line patch puts performance of 2.2.19 back to
2.2.18 for me and I use it for a week without any problems.

Beware that I am not a kernel hacker so the patch can be completely 
wrong. But I hope it still can provide some useful information to 
somebody  who really knows what is going on here :)

oleg

[-- Attachment #2: linux-2.2.19-8139too.patch --]
[-- Type: application/octet-stream, Size: 265 bytes --]

--- linux-2.2.19/drivers/net/8139too.c	Sun Mar 25 20:37:34 2001
+++ linux-mole/drivers/net/8139too.c	Sat May 12 18:27:48 2001
@@ -1808,6 +1808,7 @@
 		tp->dirty_tx = dirty_tx;
 		if (netif_queue_stopped (dev))
 			netif_wake_queue (dev);
+		mark_bh(NET_BH);
 	}
 }

^ permalink raw reply	[flat|nested] 3+ messages in thread

* netif_wake_queue wrong was Re: [PATCH] NFS Server performance and 8139too
  2001-05-13  7:32 [PATCH] NFS Server performance and 8139too Oleg Makarenko
@ 2001-05-13 10:53 ` Andi Kleen
  2001-05-14 11:40   ` netif_wake_queue wrong was: " Oleg Makarenko
  0 siblings, 1 reply; 3+ messages in thread
From: Andi Kleen @ 2001-05-13 10:53 UTC (permalink / raw)
  To: Oleg Makarenko; +Cc: linux-kernel, ipv4, Alan Cox

On Sun, May 13, 2001 at 11:32:00AM +0400, Oleg Makarenko wrote:
> Beware that I am not a kernel hacker so the patch can be completely 
> wrong. But I hope it still can provide some useful information to 
> somebody  who really knows what is going on here :)

The problem is that the netif_wake_queue() 2.4 compatibility macro that
was recently added to 2.2 was wrong. It should do a mark_bh(). 8139too
uses the 2.4 macros, and therefore the netbh was always scheduled for too
late and performance was bad.

This patch should fix all drivers that use the new framework.


--- linux/include/linux/kcomp.h	Tue Dec 19 17:57:30 2000
+++ linux-work/include/linux/kcomp.h	Sun May 13 13:01:11 2001
@@ -17,7 +17,7 @@
 
 #define	net_device			device
 #define dev_kfree_skb_irq(a)		dev_kfree_skb(a)
-#define netif_wake_queue(dev)		clear_bit(0, &dev->tbusy)
+#define netif_wake_queue(dev)		do { clear_bit(0, &dev->tbusy); mark_bh(NET_BH); } while(0)
 #define netif_stop_queue(dev)		set_bit(0, &dev->tbusy)
 #define netif_start_queue(dev)		do { dev->tbusy = 0; dev->interrupt = 0; dev->start = 1; } while (0)
 #define netif_queue_stopped(dev)	dev->tbusy



-Andi

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: netif_wake_queue wrong was: [PATCH] NFS Server performance and  8139too
  2001-05-13 10:53 ` netif_wake_queue wrong was " Andi Kleen
@ 2001-05-14 11:40   ` Oleg Makarenko
  0 siblings, 0 replies; 3+ messages in thread
From: Oleg Makarenko @ 2001-05-14 11:40 UTC (permalink / raw)
  To: linux-kernel; +Cc: Andi Kleen, jgarzik

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

Andi Kleen wrote:
> 
> On Sun, May 13, 2001 at 11:32:00AM +0400, Oleg Makarenko wrote:
> > Beware that I am not a kernel hacker so the patch can be completely
> > wrong. But I hope it still can provide some useful information to
> > somebody  who really knows what is going on here :)
> 
> The problem is that the netif_wake_queue() 2.4 compatibility macro that
> was recently added to 2.2 was wrong. It should do a mark_bh(). 8139too
> uses the 2.4 macros, and therefore the netbh was always scheduled for too
> late and performance was bad.
> 
> This patch should fix all drivers that use the new framework.
> 

Unfortunately it doesn't. 8139too (and every other driver in 2.2.19 
source tree) uses its own version of netif_wake_queue(). So your patch
doesn't solve the problem with 8139too.

Here is another patch for 8139too that places mark_bh() into the 
netif_wake_queue() macro definition in 8139too.c. 

Or with you patch for kcomp.h is it now better to completely remove 
the macro redefinition from 8139too.c?

My first patch is more of reverse type as it places mark_bh() 
(that was lost) right after the netif_wake_queue() and 
calls mark_bh() more often than it wakes the queue in a manner 
of the older (working) 8139too version.

oleg

[-- Attachment #2: linux-2.2.19-8139too.patch --]
[-- Type: application/octet-stream, Size: 471 bytes --]

--- linux-2.2.20pre2/drivers/net/8139too.c	Mon May 14 11:16:30 2001
+++ linux-mole/drivers/net/8139too.c	Mon May 14 11:17:22 2001
@@ -187,7 +187,7 @@
 #endif
 
 #define dev_kfree_skb_irq(a)	dev_kfree_skb(a)
-#define netif_wake_queue(dev)	clear_bit(0, &dev->tbusy)
+#define netif_wake_queue(dev)	do { clear_bit(0, &dev->tbusy) ; mark_bh(NET_BH); } while(0)
 #define netif_stop_queue(dev)	set_bit(0, &dev->tbusy)
 
 static inline void netif_start_queue(struct device *dev)

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-05-14  7:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-13  7:32 [PATCH] NFS Server performance and 8139too Oleg Makarenko
2001-05-13 10:53 ` netif_wake_queue wrong was " Andi Kleen
2001-05-14 11:40   ` netif_wake_queue wrong was: " Oleg Makarenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).