Re: skge/sk98lin slowdown with 4 Gb memory compared to 2 Gb memory

[thunder7@xs4all.nl]

From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, Mar 10, 2006 at 01:28:38PM -0800
> I suspect the optimization (in other drivers as well) that doesn't set 64 bit mask
> unless dma addresses are 64 bit. The problem would go away if you config for 64G of
> memory.
> 
> This unconditionally sets 64 bit mask, does it change the situation?
> 
> --- linux-2.6.orig/drivers/net/skge.c	2006-03-10 13:26:29.000000000 -0800
> +++ linux-2.6/drivers/net/skge.c	2006-03-10 13:12:38.000000000 -0800
> @@ -3265,16 +3265,10 @@
>  
>  	pci_set_master(pdev);
>  
> -	if (sizeof(dma_addr_t) > sizeof(u32) &&
> -	    !(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))) {
> +	if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK) &&
> +	    !pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK))
>  		using_dac = 1;
> -		err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
> -		if (err < 0) {
> -			printk(KERN_ERR PFX "%s unable to obtain 64 bit DMA "
> -			       "for consistent allocations\n", pci_name(pdev));
> -			goto err_out_free_regions;
> -		}
> -	} else {
> +	else {
>  		err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
>  		if (err) {
>  			printk(KERN_ERR PFX "%s no usable DMA configuration\n",
> 
It makes a difference, with this patch:

INTEL :free
             total       used       free     shared    buffers     cached
Mem:       4043388     263432    3779956          0      23340      50576
-/+ buffers/cache:     189516    3853872
Swap:      4200888          0    4200888
INTEL :ping rusalka
PING rusalka.of.nowhere (192.168.0.3) 56(84) bytes of data.
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=2 ttl=128 time=4012 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

--- rusalka.of.nowhere ping statistics ---
29 packets transmitted, 1 received, 96% packet loss, time 47037ms
rtt min/avg/max/mdev = 4012.565/4012.565/4012.565/0.000 ms, pipe 5
INTEL :

and with this patch, booting with mem=3G:

INTEL :ping rusalka
PING rusalka.of.nowhere (192.168.0.3) 56(84) bytes of data.
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=1 ttl=128 time=0.253 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=2 ttl=128 time=0.233 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=3 ttl=128 time=0.246 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=4 ttl=128 time=0.262 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=5 ttl=128 time=0.261 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=6 ttl=128 time=0.262 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=7 ttl=128 time=0.269 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=8 ttl=128 time=0.260 ms
64 bytes from rusalka.of.nowhere (192.168.0.3): icmp_seq=9 ttl=128 time=0.269 ms

--- rusalka.of.nowhere ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8000ms
rtt min/avg/max/mdev = 0.233/0.257/0.269/0.015 ms
INTEL :

So I don't think this patch is the solution you and I hoped for.

Sorry,
Jurriaan
-- 
We the unwilling, led by the unknowing have been doing the difficult
with little for so long that we are now ready to tackle the
impossible with nothing.
	Fire Communications Reserve Volunteer Motto
Debian (Unstable) GNU/Linux 2.6.16-rc5-mm2 5503 bogomips load 0.29
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/