On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
> In a VLDB like workload this would enable me to lower the latency of
> common fast requests and. By fast requests I mean ones that do not
> require much data, the data is cached, or there's a predictable read
> pattern (read-ahead).
On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
In a VLDB like workload this would enable me to lower the latency of
common fast requests and. By fast requests I mean ones that do not
require much data, the data is cached, or there's a predictable read
pattern (read-ahead).
On Fri, Sep 5, 2014 at 12:32 PM, Christoph Hellwig wrote:
> On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
>> I would prefer a interface more like recv() where I can specify the
>> flag if I want blocking behavior for this read or not. Let me explain
>> why:
>>
>> In a VLDB like
On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
> I would prefer a interface more like recv() where I can specify the
> flag if I want blocking behavior for this read or not. Let me explain
> why:
>
> In a VLDB like workload this would enable me to lower the latency of
> common
I would prefer a interface more like recv() where I can specify the
flag if I want blocking behavior for this read or not. Let me explain
why:
In a VLDB like workload this would enable me to lower the latency of
common fast requests and. By fast requests I mean ones that do not
require much data,
On Fri, Sep 05, 2014 at 12:02:19PM -0400, Jeff Moyer wrote:
> > One further consideration would be to finally implement real buffered
> > I/O in kernel space by something like the above and offloading to
> > workqueues in kernelspace. I think our workqueues now are way better
> > than any
Christoph Hellwig writes:
> On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote:
>> I suggest you look at the recent fincore debate. It did not progress much
>> the last time because the author wanted to push a lot of functionality in
>> there where as reviewers felt it should start
On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote:
> I suggest you look at the recent fincore debate. It did not progress much
> the last time because the author wanted to push a lot of functionality in
> there where as reviewers felt it should start simple. The simple case is
> likely a
On Thu, Jul 24, 2014 at 10:36:33PM -0400, Milosz Tanski wrote:
> After spending some time of my own fighting similar problems I figured
> I'd reach out to see if there's something that can be done that can
> make my use case easier. I was wondering if there is a read family
> syscall that allows
On Thu, Jul 24, 2014 at 10:36:33PM -0400, Milosz Tanski wrote:
After spending some time of my own fighting similar problems I figured
I'd reach out to see if there's something that can be done that can
make my use case easier. I was wondering if there is a read family
syscall that allows me to
On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote:
I suggest you look at the recent fincore debate. It did not progress much
the last time because the author wanted to push a lot of functionality in
there where as reviewers felt it should start simple. The simple case is
likely a
Christoph Hellwig h...@infradead.org writes:
On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote:
I suggest you look at the recent fincore debate. It did not progress much
the last time because the author wanted to push a lot of functionality in
there where as reviewers felt it should
On Fri, Sep 05, 2014 at 12:02:19PM -0400, Jeff Moyer wrote:
One further consideration would be to finally implement real buffered
I/O in kernel space by something like the above and offloading to
workqueues in kernelspace. I think our workqueues now are way better
than any possible user
I would prefer a interface more like recv() where I can specify the
flag if I want blocking behavior for this read or not. Let me explain
why:
In a VLDB like workload this would enable me to lower the latency of
common fast requests and. By fast requests I mean ones that do not
require much data,
On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
I would prefer a interface more like recv() where I can specify the
flag if I want blocking behavior for this read or not. Let me explain
why:
In a VLDB like workload this would enable me to lower the latency of
common fast
On Fri, Sep 5, 2014 at 12:32 PM, Christoph Hellwig h...@infradead.org wrote:
On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
I would prefer a interface more like recv() where I can specify the
flag if I want blocking behavior for this read or not. Let me explain
why:
In a VLDB
Mel,
I've been following your recent work with the postgres folks to
improve the kernel for postgres like workloads (which can really help
all database like loads).
After spending some time of my own fighting similar problems I figured
I'd reach out to see if there's something that can be done
Mel,
I've been following your recent work with the postgres folks to
improve the kernel for postgres like workloads (which can really help
all database like loads).
After spending some time of my own fighting similar problems I figured
I'd reach out to see if there's something that can be done
18 matches
Mail list logo
