Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S289182AbSANKRE>; Mon, 14 Jan 2002 05:17:04 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S289184AbSANKQw>; Mon, 14 Jan 2002 05:16:52 -0500
Received: from vasquez.zip.com.au ([203.12.97.41]:1804 "EHLO
	vasquez.zip.com.au") by vger.kernel.org with ESMTP
	id <S289182AbSANKQk>; Mon, 14 Jan 2002 05:16:40 -0500
Message-ID: <3C42AD48.FCFD6056@zip.com.au>
Date: Mon, 14 Jan 2002 02:04:56 -0800
From: Andrew Morton <akpm@zip.com.au>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18pre1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephan von Krawczynski <skraw@ithnet.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>, zippel@linux-m68k.org, rml@tech9.net,
        ken@canit.se, arjan@fenrus.demon.nl, landley@trommello.org,
        linux-kernel@vger.kernel.org
Subject: Re: [2.4.17/18pre] VM and swap - it's really unusable
In-Reply-To: <E16PvKx-00005L-00@the-village.bc.nu>,
		<200201140033.BAA04292@webserver.ithnet.com>
		<E16PvKx-00005L-00@the-village.bc.nu> <20020114104532.59950d86.skraw@ithnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Stephan von Krawczynski wrote:
> 
> ...
> Unfortunately me have neither of those. This would mean I cannot benefit from
> _these_ patches, but instead would need _others_ (like tulip or
> name-one-of-the-rest-of-the-drivers) to see _some_ effect you tell me I
> _should_ see (I currently see _none_). How do you argue then against the
> statement: we need patches for /drivers/net/*.c ?? I do not expect 3c59x.c to
> be particularly bad in comparison to tulip/*.c or lets say via-rhine.c, do you?
> 

In 3c59x.c, probably the biggest problem will be the call to issue_and_wait()
in boomerang_start_xmit().  On a LAN which is experiencing heavy collision rates
this can take as long as 2,000 PCI cycles (it's quite rare, and possibly an
erratum).  It is called under at least two spinlocks.

In via-rhine, wait_for_reset() can busywait for up to ten milliseconds.
via_rhine_tx_timeout() calls it from under a spinlock.

In eepro100.c, wait_for_cmd_done() can busywait for one millisecond
and is called multiple times under spinlock.



Preemption will help _some_ of this, but by no means all, or enough.

-
-
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/