Subject: Re: [RFC] kill sleep_on
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Andrew Morton <akpm@osdl.org>
Cc: dwmw2@infradead.org,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       manfred@colorfullife.com, linux-kernel@vger.kernel.org
In-Reply-To: <20040117233618.094c9d22.akpm@osdl.org>
References: <40098251.2040009@colorfullife.com>
	 <1074367701.9965.2.camel@imladris.demon.co.uk>
	 <20040117201000.GL21151@parcelfarce.linux.theplanet.co.uk>
	 <1074383111.9965.4.camel@imladris.demon.co.uk>
	 <20040117224139.5585fb9c.akpm@osdl.org>
	 <1074409074.1569.12.camel@nidelv.trondhjem.org>
	 <20040117233618.094c9d22.akpm@osdl.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Message-Id: <1074412497.1569.32.camel@nidelv.trondhjem.org>
Mime-Version: 1.0
Date: Sun, 18 Jan 2004 02:54:57 -0500
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 970
Lines: 21

P? su , 18/01/2004 klokka 02:36, skreiv Andrew Morton:
> That's quite a lot of contention on the lock_kernel() in remote_llseek().

The NFS use of the BKL may indeed end up leading to latencies within
llseek(), but what you just presented is more of an argument for
eliminating the use of the BKL within llseek()...

In general, though, the latencies involved with the actual RPC call are
so large that anything involving local locks will not tend to register
on the radar screen at all (your numbers for "default_idle" are an order
of magnitude larger than anything else).
This is certainly true of 100Mbit nets. However those latencies might
perhaps start to be measurable on GigE nets with fast servers...

Cheers,
  Trond
-
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/