[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150330203227.GA4987@samba2>
Date: Mon, 30 Mar 2015 13:32:27 -0700
From: Jeremy Allison <jra@...ba.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Jeremy Allison <jra@...ba.org>,
Milosz Tanski <milosz@...in.com>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-aio@...ck.org,
Mel Gorman <mgorman@...e.de>,
Volker Lendecke <Volker.Lendecke@...net.de>,
Tejun Heo <tj@...nel.org>, Jeff Moyer <jmoyer@...hat.com>,
Theodore Ts'o <tytso@....edu>,
Al Viro <viro@...iv.linux.org.uk>, linux-api@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>,
linux-arch@...r.kernel.org, Dave Chinner <david@...morbit.com>
Subject: Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache
only)
On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote:
>
> cons:
>
> d) fincore() is more expensive
>
> e) fincore() will very occasionally block
The above is the killer for Samba. If fincore
returns true but when we schedule the pread
we block, we're hosed.
Once we block, we're done serving clients on the main
thread until this returns. That can cause unpredictable
response times which can cause client timeouts.
A fincore+pread solution that blocks is simply unsafe
to use for us. We'll have to stay with the threadpool :-(.
> And I don't believe that e) will be a problem in the real world. It's
> a significant increase in worst-case latency and a negligible increase
> in average latency. I've asked at least three times for someone to
> explain why this is unacceptable and no explanation has been provided.
See above.
--
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/
Powered by blists - more mailing lists