From: Ming Lei <ming.lei@canonical.com>
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jens Axboe <axboe@kernel.dk>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
"Justin M. Forbes" <jforbes@fedoraproject.org>,
Jeff Moyer <jmoyer@redhat.com>, Tejun Heo <tj@kernel.org>,
Christoph Hellwig <hch@infradead.org>,
"v4.0" <stable@vger.kernel.org>
Subject: Re: [PATCH 2/2] block: loop: avoiding too many pending per work I/O
Date: Fri, 22 May 2015 21:32:34 +0800 [thread overview]
Message-ID: <CACVXFVPWPCBiZ3KaxM2ABQuiHhoY2dpZbxRnms3E7RvoMDpgqQ@mail.gmail.com> (raw)
In-Reply-To: <CA+5PVA5G5ZoAEwn-+ZmHn6Vh5CuH9U_egXxsHSWP_TGi3HdKkQ@mail.gmail.com>
On Fri, May 22, 2015 at 8:36 PM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, May 5, 2015 at 7:49 AM, Ming Lei <ming.lei@canonical.com> 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_active parameter of workqueue as 16.
>>
>> This patch fixes Fedora 22 live booting performance
>> regression when it is booted from squashfs over dm
>> based on loop, and looks the following reasons are
>> related with the problem:
>>
>> - not like other filesyststems(such as ext4), squashfs
>> is a bit special, and I observed that increasing I/O jobs
>> to access file in squashfs only improve I/O performance a
>> little, but it can make big difference for ext4
>>
>> - nested loop: both squashfs.img and ext3fs.img are mounted
>> as loop block, and ext3fs.img is inside the squashfs
>>
>> - during booting, lots of tasks may run concurrently
>>
>> Fixes: b5dd2f6047ca108001328aac0e8588edd15f1778
>> Cc: stable@vger.kernel.org (v4.0)
>> Cc: Justin M. Forbes <jforbes@fedoraproject.org>
>> Signed-off-by: Ming Lei <ming.lei@canonical.com>
>
> Did we ever come to conclusion on this and patch 1/2 in the series?
> Fedora has them applied to it's 4.0.y based kernels to fix the
> performance regression we saw, and we're carrying them in rawhide as
> well. I'm curious if these will go into 4.1 or if they're queued at
> all for 4.2?
I saw it queued in for-next branch of block tree, so it should be merged
to 4.2.
>
> josh
>
>> ---
>> drivers/block/loop.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
>> index 3dc1598..1bee523 100644
>> --- a/drivers/block/loop.c
>> +++ b/drivers/block/loop.c
>> @@ -725,7 +725,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
>> goto out_putf;
>> error = -ENOMEM;
>> lo->wq = alloc_workqueue("kloopd%d",
>> - WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0,
>> + WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 16,
>> lo->lo_number);
>> if (!lo->wq)
>> goto out_putf;
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe stable" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-05-22 13:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 11:49 [PATCH 0/2] block: loop: fix stacked loop and performance regression Ming Lei
2015-05-05 11:49 ` [PATCH 1/2] block: loop: convert to per-device workqueue Ming Lei
2015-05-05 14:00 ` Tejun Heo
2015-05-26 22:29 ` Dave Kleikamp
2015-05-05 11:49 ` [PATCH 2/2] block: loop: avoiding too many pending per work I/O Ming Lei
2015-05-05 13:59 ` Tejun Heo
2015-05-05 14:46 ` Ming Lei
2015-05-05 16:55 ` Tejun Heo
2015-05-06 3:14 ` Ming Lei
2015-05-06 5:17 ` Ming Lei
2015-05-06 7:36 ` Christoph Hellwig
2015-05-06 11:43 ` Ming Lei
2015-05-22 12:36 ` Josh Boyer
2015-05-22 13:32 ` Ming Lei [this message]
2015-05-05 19:01 ` [PATCH 0/2] block: loop: fix stacked loop and performance regression Justin M. Forbes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACVXFVPWPCBiZ3KaxM2ABQuiHhoY2dpZbxRnms3E7RvoMDpgqQ@mail.gmail.com \
--to=ming.lei@canonical.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=jforbes@fedoraproject.org \
--cc=jmoyer@redhat.com \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®