linux-kernel - Re: [Bugme-new] [Bug 12564] New: poor performance while preprocessing source code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1233235656.9785.104.camel@heimdal.trondhjem.org>
Date:	Thu, 29 Jan 2009 08:27:36 -0500
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Steven Patrick <steven@...s.net>, jlayton@...hat.com,
	bugme-daemon@...zilla.kernel.org, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Bugme-new] [Bug 12564] New: poor performance while
 preprocessing source code

On Wed, 2009-01-28 at 17:37 -0800, Andrew Morton wrote:
> On Wed, 28 Jan 2009 17:02:36 -0800
> Steven Patrick <steven@...s.net> wrote:
> 
> > On Wed, 2009-01-28 at 17:05 -0500, Jeff Layton wrote:
> > > 
> > > It's a pretty small patch. The obvious question is: "What mount
> > > options
> > > are you using on your NFS mounts?"
> > > 
> > 
> >   Well, I didn't think that I was using any NFS mounts.
> > But, it turns out I was in a way.  Apparently, amd does its top
> > level mounts with noac.  So, where this (using an automounted path):
> >     cd /h/spo/work
> >     make -j 5
> > would be slow.  This (using a non-automounted path):
> >     cd /home/spo/work
> >     make -j 5
> > showed the faster performance I was expecting.
> >   I will mark my bug as invalid and decide what, if anything,
> > I want to do about amd.
> >   Thanks for pointing me in the right direction.
> > 
> 
> This had me all mystified until I clicked on the bugzilla link:
> 
> 
> :  ------- Comment  #9 From Trond Myklebust  2009-01-28 13:58:50  [reply] -------
> : 
> : If you are worried about performance, why are you using noac/actimeo=0?
> : 
> : The commit you point to fixed a bug in which the noac/actimeo=0 was
> : using cached metadata in situations where it should have been
> : retrieving the data from the server.  We fully expect a significant
> : performance drop when the client is forced to send more GETATTR
> : requests to the server, and as I said, that was precisely the point of
> : this fix.
> 
> Fair enough.
> 
> 
> 
> However.  We surprised one user (yourself), and we will presumably
> surprise others.  Or, worse, we will slow down people's stuff and they
> won't even notice.
> 
> Should we perhaps warn people about this?  A mount-time printk telling
> them that moac/actime=0 is slow?

No. The current nfs manpages (dated 2 November 2007) have a whole
section on data and metadata coherence and about the trade-offs
involved. That section is explicitly referenced in the description of
the 'noac' mount option. It explains that 'noac' is basically about
disabling caching in order to achieve approximate cache coherent
behaviour when multiple NFS clients need to access files that are being
modified frequently on the server.

Note that 'noac' has _never_ been intended as a default NFS mount
option. The kernel default is rather to cache attributes as aggressively
as possible for scalability and performance reasons.
All other NFS mount programs therefore require 'noac' to be explicitly
set by the user. I see no reason to punish those users with extra printk
spam.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/