Re: [Bugme-new] [Bug 12564] New: poor performance whilepreprocessing source code

[Andrew Morton]

On Wed, 28 Jan 2009 17:02:36 -0800
Steven Patrick <steven@xxxxxxxx> 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?

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