On Fri, Apr 3, 2015 at 11:42 PM, Andrew Morton
wrote:
> On Mon, 30 Mar 2015 13:26:25 -0700 Andrew Morton
> wrote:
>
>> d) fincore() is more expensive
>
> Actually, I kinda take that back. fincore() will be faster than
> preadv2() in the case of a pagecache miss, and slower in the case of a
> pa
On Mon, 30 Mar 2015 13:26:25 -0700 Andrew Morton
wrote:
> d) fincore() is more expensive
Actually, I kinda take that back. fincore() will be faster than
preadv2() in the case of a pagecache miss, and slower in the case of a
pagecache hit.
The breakpoint appears to be a hit rate of 30% - if fe
On Fri, Mar 27, 2015 at 12:30 PM, Andrew Morton
wrote:
> On Fri, 27 Mar 2015 08:58:54 -0700 Jeremy Allison wrote:
>
>> On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote:
>> > On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig
>> > wrote:
>> >
>> > > On Fri, Mar 27, 2015 at 01:35:1
On Mon, Mar 30, 2015 at 4:26 PM, Andrew Morton
wrote:
> On Mon, 30 Mar 2015 00:36:04 -0700 Christoph Hellwig
> wrote:
>
>> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
>> > The problem with the above is that we can't tell the difference
>> > between pread2() returning a short
On Mon, Mar 30, 2015 at 3:36 AM, Christoph Hellwig wrote:
> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
>> The problem with the above is that we can't tell the difference
>> between pread2() returning a short read because the pages are not
>> in cache, or because someone trunca
On Mon, Mar 30, 2015 at 6:57 PM, Andrew Morton
wrote:
> On Mon, 30 Mar 2015 18:49:06 -0400 Milosz Tanski wrote:
>
>> > A fincore+pread solution that blocks is simply unsafe
>> > to use for us. We'll have to stay with the threadpool :-(.
>>
>> We're getting data from a network filesystem Ceph in o
On Mon, 30 Mar 2015 18:49:06 -0400 Milosz Tanski wrote:
> > A fincore+pread solution that blocks is simply unsafe
> > to use for us. We'll have to stay with the threadpool :-(.
>
> We're getting data from a network filesystem Ceph in our case, but it
> could be pNFS. In many cases those filesyst
On Mon, Mar 30, 2015 at 1:19 PM, Jeremy Allison wrote:
> On Mon, Mar 30, 2015 at 12:36:04AM -0700, Christoph Hellwig wrote:
>> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
>> > The problem with the above is that we can't tell the difference
>> > between pread2() returning a shor
On Mon, 30 Mar 2015 18:40:16 -0400 Milosz Tanski wrote:
> On Mon, Mar 30, 2015 at 2:54 PM, Andrew Morton
> wrote:
> > On Mon, 30 Mar 2015 00:40:20 -0700 Christoph Hellwig
> > wrote:
> >
> >> On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:
> >> > mm... I don't think we should be
On Mon, Mar 30, 2015 at 4:32 PM, Jeremy Allison wrote:
> 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 sche
On Mon, Mar 30, 2015 at 2:54 PM, Andrew Morton
wrote:
> On Mon, 30 Mar 2015 00:40:20 -0700 Christoph Hellwig
> wrote:
>
>> On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:
>> > mm... I don't think we should be adding placeholders to the kernel API
>> > to support code which hasn't
On Mon, Mar 30, 2015 at 4:37 PM, Andrew Morton
wrote:
> On Mon, 30 Mar 2015 13:32:27 -0700 Jeremy Allison wrote:
>
>> 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
>>
>> T
On Mon, 30 Mar 2015 13:49:37 -0700 Jeremy Allison wrote:
> > This implies that the samba main thread also has to avoid any memory
> > allocations both direct and within syscall and pagefault - those will
> > occasionally exhibit similar worse-case latency. Is this done now?
>
> We don't do anyth
On Mon, Mar 30, 2015 at 01:37:58PM -0700, Andrew Morton wrote:
> On Mon, 30 Mar 2015 13:32:27 -0700 Jeremy Allison wrote:
>
> > On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote:
> > >
> > > cons:
> > >
> > > d) fincore() is more expensive
> > >
> > > e) fincore() will very occasio
On Mon, 30 Mar 2015 13:32:27 -0700 Jeremy Allison wrote:
> 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
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 s
On Mon, 30 Mar 2015 00:36:04 -0700 Christoph Hellwig wrote:
> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
> > The problem with the above is that we can't tell the difference
> > between pread2() returning a short read because the pages are not
> > in cache, or because someone
On Mon, 30 Mar 2015 00:40:20 -0700 Christoph Hellwig wrote:
> On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:
> > mm... I don't think we should be adding placeholders to the kernel API
> > to support code which hasn't been written, tested, reviewed, merged,
> > etc. It's possible
On Mon, Mar 30, 2015 at 12:36:04AM -0700, Christoph Hellwig wrote:
> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
> > The problem with the above is that we can't tell the difference
> > between pread2() returning a short read because the pages are not
> > in cache, or because som
On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:
> mm... I don't think we should be adding placeholders to the kernel API
> to support code which hasn't been written, tested, reviewed, merged,
> etc. It's possible none of this will ever happen and we end up with a
> syscall nobody n
On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
> The problem with the above is that we can't tell the difference
> between pread2() returning a short read because the pages are not
> in cache, or because someone truncated the file. So we need some
> way to differentiate this.
Is a
On Fri, 27 Mar 2015 11:21:26 -0400 Milosz Tanski wrote:
> On Thu, Mar 26, 2015 at 11:28 PM, Andrew Morton
> wrote:
> > On Mon, 16 Mar 2015 14:27:10 -0400 Milosz Tanski wrote:
> >
> >> This patchset introduces two new syscalls preadv2 and pwritev2. They are
> >> the
> >> same syscalls as preadv
On Fri, Mar 27, 2015 at 12:30 PM, Andrew Morton
wrote:
> On Fri, 27 Mar 2015 08:58:54 -0700 Jeremy Allison wrote:
>
>> On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote:
>> > On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig
>> > wrote:
>> >
>> > > On Fri, Mar 27, 2015 at 01:35:1
On Fri, Mar 27, 2015 at 09:30:46AM -0700, Andrew Morton wrote:
>
> But from an interface perspective the behaviour you're asking for is
> insane, frankly - if the kernel copied out 8k of data then pread2()
> should return 8k. Otherwise there's no way for userspace to know that
> the 8k copy actua
On Fri, Mar 27, 2015 at 11:58 AM, Jeremy Allison wrote:
> On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote:
>> On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig
>> wrote:
>>
>> > On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote:
>> > > fincore() doesn't have to be ug
On Fri, 27 Mar 2015 09:30:46 -0700 Andrew Morton
wrote:
> I expect that this situation (first part in cache, latter part not in
> cache) is rare - for reasonably small requests the common cases will be
> "all cached" and "nothing cached". So perhaps the best approach here
> is for samba to add
On Fri, 27 Mar 2015 08:58:54 -0700 Jeremy Allison wrote:
> On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote:
> > On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig
> > wrote:
> >
> > > On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote:
> > > > fincore() doesn't have
On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote:
> On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig
> wrote:
>
> > On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote:
> > > fincore() doesn't have to be ugly. Please address the design issues I
> > > raised. How is p
On Thu, Mar 26, 2015 at 11:28 PM, Andrew Morton
wrote:
> On Mon, 16 Mar 2015 14:27:10 -0400 Milosz Tanski wrote:
>
>> This patchset introduces two new syscalls preadv2 and pwritev2. They are the
>> same syscalls as preadv and pwrite but with a flag argument. Additionally,
>> preadv2 implements an
On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote:
> On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig
> wrote:
>
> > On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote:
> > > fincore() doesn't have to be ugly. Please address the design issues I
> > > raised. How is p
On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig wrote:
> On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote:
> > fincore() doesn't have to be ugly. Please address the design issues I
> > raised. How is pread2() useful to the class of applications which
> > cannot proceed until a
On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote:
> fincore() doesn't have to be ugly. Please address the design issues I
> raised. How is pread2() useful to the class of applications which
> cannot proceed until all data is available?
It actually makes them work correctly? preadv2
On Fri, 27 Mar 2015 01:18:22 -0700 Christoph Hellwig wrote:
> On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote:
> > I still don't understand why pwritev() exists. We discussed this last
> > time but it seems nothing has changed. I'm not seeing here an adequate
> > description of wh
On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote:
> I still don't understand why pwritev() exists. We discussed this last
> time but it seems nothing has changed. I'm not seeing here an adequate
> description of why it exists nor a justification for its addition.
pwritev2? I have p
On Fri, Mar 27, 2015 at 09:02:51AM +0100, Volker Lendecke wrote:
> No, this is not the case. Maybe my whole understanding of
> pread is wrong: I always thought that it won't return short
> if the file spans the pread range. EINTR nonwithstanding.
Per Posix it could, however if we do it for regular
On Thu, Mar 26, 2015 at 11:08:33PM -0700, Andrew Morton wrote:
> On Fri, 27 Mar 2015 06:41:25 +0100 Volker Lendecke
> wrote:
>
> > On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote:
> > > A thing which bugs me about pread2() is that it is specifically
> > > tailored to applications w
On Fri, 27 Mar 2015 06:41:25 +0100 Volker Lendecke
wrote:
> On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote:
> > A thing which bugs me about pread2() is that it is specifically
> > tailored to applications which are able to use a partial read result.
> > ie, by sending it over the
On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote:
> A thing which bugs me about pread2() is that it is specifically
> tailored to applications which are able to use a partial read result.
> ie, by sending it over the network.
Can you explain what you mean by this? Samba gets a pread
On Mon, 16 Mar 2015 14:27:10 -0400 Milosz Tanski wrote:
> This patchset introduces two new syscalls preadv2 and pwritev2. They are the
> same syscalls as preadv and pwrite but with a flag argument. Additionally,
> preadv2 implements an extra RWF_NONBLOCK flag.
I still don't understand why pwrit
On Thu, Mar 26, 2015 at 3:12 PM, Milosz Tanski wrote:
> On Thu, Mar 26, 2015 at 7:55 AM, Christoph Hellwig wrote:
>>
>> On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote:
>> > This patchset introduces two new syscalls preadv2 and pwritev2. They are
>> > the
>> > same syscalls as prea
On Thu, Mar 26, 2015 at 7:55 AM, Christoph Hellwig wrote:
>
> On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote:
> > This patchset introduces two new syscalls preadv2 and pwritev2. They are the
> > same syscalls as preadv and pwrite but with a flag argument. Additionally,
> > preadv2 i
On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote:
> This patchset introduces two new syscalls preadv2 and pwritev2. They are the
> same syscalls as preadv and pwrite but with a flag argument. Additionally,
> preadv2 implements an extra RWF_NONBLOCK flag.
There was some arugment that
This patchset introduces two new syscalls preadv2 and pwritev2. They are the
same syscalls as preadv and pwrite but with a flag argument. Additionally,
preadv2 implements an extra RWF_NONBLOCK flag.
The RWF_NONBLOCK flag in preadv2 introduces an ability to perform a
non-blocking read from regular
43 matches
Mail list logo
