All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux v2.6.17-rc6
Date: Wed, 7 Jun 2006 09:29:28 +0200	[thread overview]
Message-ID: <20060607072928.GR15032@unthought.net> (raw)
In-Reply-To: <4485AED0.9030004@tmr.com>

On Tue, Jun 06, 2006 at 12:35:28PM -0400, Bill Davidsen wrote:
> Trond Myklebust wrote:
> >On Tue, 2006-06-06 at 14:07 +0200, Klaus S. Madsen wrote:
> >>Hi,
> >>
> >>We still experience the NFS client slow down reported by Jakob
> >>Østergaard in http://lkml.org/lkml/2006/3/31/82, even with 2.6.17-rc6.
> >>
> >>Trond Myklebust have created a patch which we have verified solves this
> >>problem for 2.6.16, 2.6.17-rc4 and 2.6.17-rc6. The patch is available
> >>from http://lkml.org/lkml/2006/4/24/320, and as an attachment to
> >>bugzilla bug 6557.
> >
> >The patch is already queued up for inclusion in 2.6.18. I'm not planning
> >on submitting it for 2.6.17 since it is not a critical bug.
> 
> I guess that depends on how much it slows down and how much you depend 
> on the speed of NFS. I have all of my machines sharing some local 
> binaries and docs, but the files are typically small and the network is 
> gigE, so I doubt it will hurt me. 

It hurts writing, not reading.  And only certain cases of writing.

But when it hurts it hurts quite a bit; slowdown is 10-20 times and gigE
most likely won't matter.

> On the other hand I do know people 
> running workstations with virtually everything NFS mounted, working with 
> large image files.
> 
> The initial bug report makes it look as if it's about two orders of 
> magnitude slower, but doesn't quantify the effect on more common 
> sequential access operations.

Sequential read and write seems to be fine. At least from my testing.

This was what made this so weird; normal testing with dd or bonnie etc.
showed all was fine. But link jobs over NFS were unreasonably slow.
Turned out you needed a somewhat special read/write pattern (similar to
ld) to trigger the slowdown.

So I guess it's probably mostly people who do development over NFS who
are hurt - and then only those who produce rather large executables.

> If this becomes an issue in 2.6.17, I hope it will show up in -stable 
> before 2.6.18, the current development cycle is a bit, um, protracted... 
> lately.

Me too :)

-- 

 / jakob


  reply	other threads:[~2006-06-07  7:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-06  1:12 Linux v2.6.17-rc6 Linus Torvalds
2006-06-06 12:07 ` Klaus S. Madsen
2006-06-06 15:27   ` Trond Myklebust
2006-06-06 16:35     ` Bill Davidsen
2006-06-07  7:29       ` Jakob Oestergaard [this message]
2006-06-06 16:09 ` Linux v2.6.17-rc6 -- alpha-generic-hweight-build-fix.patch missing Ernst Herzberg
2006-06-06 17:03 ` Linux v2.6.17-rc6 Jeff Chua
2006-06-08  0:15   ` Corey Minyard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060607072928.GR15032@unthought.net \
    --to=jakob@unthought.net \
    --cc=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.