On Sun, May 3, 2015 at 9:52 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, May 02, 2015 at 10:56:20PM +0800, Ming Lei wrote:
>> > Maybe just cap max_active to NR_OF_LOOP_DEVS * 16 or sth? But idk,
>>
>> It might not work because there are nested loop devices like fedora live CD,
>> and
>> in theory t
Hello,
On Sat, May 02, 2015 at 10:56:20PM +0800, Ming Lei wrote:
> > Maybe just cap max_active to NR_OF_LOOP_DEVS * 16 or sth? But idk,
>
> It might not work because there are nested loop devices like fedora live CD,
> and
> in theory the max_active should have been set as loop's queue depth *
On Fri, May 1, 2015 at 11:47 PM, Tejun Heo wrote:
> On Fri, May 01, 2015 at 08:05:45AM -0700, Christoph Hellwig wrote:
>> > Maybe just cap max_active to NR_OF_LOOP_DEVS * 16 or sth? But idk,
>> > how many concurrent workers are we talking about and why are we
>> > capping per-queue concurrency fr
On Fri, May 1, 2015 at 10:22 PM, Tejun Heo wrote:
> On Fri, May 01, 2015 at 09:36:47PM +0800, Ming Lei wrote:
>> On Fri, May 1, 2015 at 6:17 PM, Christoph Hellwig wrote:
>> > On Fri, May 01, 2015 at 11:28:01AM +0800, Ming Lei wrote:
>> >> If there are too many pending per work I/O, too many
>> >>
On Fri, May 01, 2015 at 08:05:45AM -0700, Christoph Hellwig wrote:
> > Maybe just cap max_active to NR_OF_LOOP_DEVS * 16 or sth? But idk,
> > how many concurrent workers are we talking about and why are we
> > capping per-queue concurrency from worker pool side instead of command
> > tag side?
>
On Fri, May 01, 2015 at 10:22:21AM -0400, Tejun Heo wrote:
> > > Why would you do this fall back? Shouldn't we just communicate
> > > a concurrency limit to the workqueue code?
> >
> > It can't work with workqueue's concurrency limit because the
> > queue is shared by all loop block devices, and
On Fri, May 01, 2015 at 09:36:47PM +0800, Ming Lei wrote:
> On Fri, May 1, 2015 at 6:17 PM, Christoph Hellwig wrote:
> > On Fri, May 01, 2015 at 11:28:01AM +0800, Ming Lei wrote:
> >> If there are too many pending per work I/O, too many
> >> high priority work thread can be generated so that
> >>
On Fri, May 1, 2015 at 6:17 PM, Christoph Hellwig wrote:
> On Fri, May 01, 2015 at 11:28:01AM +0800, Ming Lei wrote:
>> If there are too many pending per work I/O, too many
>> high priority work thread can be generated so that
>> system performance can be effected.
>>
>> This patch limits the max
On Fri, May 01, 2015 at 11:28:01AM +0800, Ming Lei wrote:
> If there are too many pending per work I/O, too many
> high priority work thread can be generated so that
> system performance can be effected.
>
> This patch limits the max pending per work I/O as 16,
> and will fackback to single queue
If there are too many pending per work I/O, too many
high priority work thread can be generated so that
system performance can be effected.
This patch limits the max pending per work I/O as 16,
and will fackback to single queue mode when the max
number is reached.
This patch fixes Fedora 22 live
10 matches
Mail list logo
