On Fri, Jun 20, 2014 at 12:30:25PM +0100, Mel Gorman wrote:
> On Fri, Jun 20, 2014 at 07:42:14AM +1000, Dave Chinner wrote:
> > On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
> > > Mel Gorman writes:
> > >
> > > > The existing CFQ default target_latency results in very poor
On Fri, Jun 20, 2014 at 07:42:14AM +1000, Dave Chinner wrote:
> On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
> > Mel Gorman writes:
> >
> > > The existing CFQ default target_latency results in very poor performance
> > > for larger numbers of threads doing sequential reads. While
On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
> Mel Gorman writes:
>
> > The existing CFQ default target_latency results in very poor performance
> > for larger numbers of threads doing sequential reads. While this can be
> > easily described as a tuning problem for users, it is
On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
Mel Gorman mgor...@suse.de writes:
The existing CFQ default target_latency results in very poor performance
for larger numbers of threads doing sequential reads. While this can be
easily described as a tuning problem for users,
On Fri, Jun 20, 2014 at 07:42:14AM +1000, Dave Chinner wrote:
On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
Mel Gorman mgor...@suse.de writes:
The existing CFQ default target_latency results in very poor performance
for larger numbers of threads doing sequential reads.
On Fri, Jun 20, 2014 at 12:30:25PM +0100, Mel Gorman wrote:
On Fri, Jun 20, 2014 at 07:42:14AM +1000, Dave Chinner wrote:
On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
Mel Gorman mgor...@suse.de writes:
The existing CFQ default target_latency results in very poor
On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
> Mel Gorman writes:
>
> > The existing CFQ default target_latency results in very poor performance
> > for larger numbers of threads doing sequential reads. While this can be
> > easily described as a tuning problem for users, it is
Mel Gorman writes:
> The existing CFQ default target_latency results in very poor performance
> for larger numbers of threads doing sequential reads. While this can be
> easily described as a tuning problem for users, it is one that is tricky
> to detect. This patch the default on the
Mel Gorman mgor...@suse.de writes:
The existing CFQ default target_latency results in very poor performance
for larger numbers of threads doing sequential reads. While this can be
easily described as a tuning problem for users, it is one that is tricky
to detect. This patch the default on
On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
Mel Gorman mgor...@suse.de writes:
The existing CFQ default target_latency results in very poor performance
for larger numbers of threads doing sequential reads. While this can be
easily described as a tuning problem for users,
The existing CFQ default target_latency results in very poor performance
for larger numbers of threads doing sequential reads. While this can be
easily described as a tuning problem for users, it is one that is tricky
to detect. This patch the default on the assumption that people with access
to
The existing CFQ default target_latency results in very poor performance
for larger numbers of threads doing sequential reads. While this can be
easily described as a tuning problem for users, it is one that is tricky
to detect. This patch the default on the assumption that people with access
to
12 matches
Mail list logo
