All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lu, Davina" <davinalu@amazon.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: "Bhatnagar, Rishabh" <risbhat@amazon.com>,
	Jan Kara <jack@suse.cz>, "jack@suse.com" <jack@suse.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Park, SeongJae" <sjpark@amazon.com>
Subject: RE: Tasks stuck jbd2 for a long time
Date: Thu, 24 Aug 2023 03:52:04 +0000	[thread overview]
Message-ID: <70943eab978e4482b9fa4f68119bc8ea@amazon.com> (raw)
In-Reply-To: <ZOOvOT4dL1SCHQDz@mit.edu>


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

> Thanks for the details.  This is something that am interested in trying to potentially to merge, since for a sufficiently coversion-heavy workload (assuming the conversion is happening 
> across multiple inodes, and not just a huge number of random writes into a single fallocated file), limiting the number of kernel threads to one CPU isn't always going to be the right thing.  
>The reason why we had done this way was because at the time, the only choices that we had was between a single kernel thread, or spawning a kernel thread for every single CPU -- 
>which for a very high-core-count system, consumed a huge amount of system resources.  This is no longer the case with the new Concurrency Managed Workqueue (cmwq), but we never 
>did the experiment to make sure cmwq didn't have surprising gotchas.

Thank you for the detailed explanation. 


> I won't have time to look at this before the next merge window, but what I'm hoping to look at is your patch at [2], with two changes:
> a)  Drop the _WQ_ORDERED flag, since it is an internal flag.
> b) Just pass in 0 for max_active instead of "num_active_cpus() > 1 ?
 > num_active_cpus() : 1", for two reasons.  Num_active_cpus() doesn't
 >  take into account CPU hotplugs (for example, if you have a
  > dynmically adjustable VM shape where the number of active CPU's
  > might change over time).  Is there a reason why we need to set that
  > limit?

> Do you see any potential problem with these changes?

Sorry for the late response, after the internal discussion, I can continue on this patch. These 2 points are easy to change, I will also do some xfstest for EXT4 and run BMS on RDS environment to do a quick verify.  We can change num_active_cpus() to 0. Why adding that: just because during fio test, the max active number goes to ~50 we won't see this issue. But this is not necessary. I will see what's Oleg's opinion later offline.

Thanks,
Davina
                                             

      reply	other threads:[~2023-08-24  3:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15 19:01 Tasks stuck jbd2 for a long time Bhatnagar, Rishabh
2023-08-16  2:28 ` Theodore Ts'o
2023-08-16  3:57   ` Bhatnagar, Rishabh
2023-08-16 14:53     ` Jan Kara
2023-08-16 18:32       ` Bhatnagar, Rishabh
2023-08-16 21:52         ` Jan Kara
2023-08-16 22:53           ` Bhatnagar, Rishabh
2023-08-17 10:49             ` Jan Kara
2023-08-17 18:59               ` Bhatnagar, Rishabh
2023-08-18  1:19                 ` Theodore Ts'o
2023-08-18  1:31                 ` Lu, Davina
2023-08-18  2:41                   ` Theodore Ts'o
2023-08-21  1:10                     ` Lu, Davina
2023-08-21 18:38                       ` Theodore Ts'o
2023-08-24  3:52                         ` Lu, Davina [this message]

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=70943eab978e4482b9fa4f68119bc8ea@amazon.com \
    --to=davinalu@amazon.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=risbhat@amazon.com \
    --cc=sjpark@amazon.com \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.