All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Bernd Schubert <bschubert@ddn.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Bernd Schubert <bernd.schubert@fastmail.fm>,
	Joanne Koong <joannelkoong@gmail.com>,
	"miklos@szeredi.hu" <miklos@szeredi.hu>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"josef@toxicpanda.com" <josef@toxicpanda.com>,
	"jefflexu@linux.alibaba.com" <jefflexu@linux.alibaba.com>,
	"laoar.shao@gmail.com" <laoar.shao@gmail.com>,
	"kernel-team@meta.com" <kernel-team@meta.com>,
	Tomasz Figa <tfiga@chromium.org>
Subject: Re: [PATCH RESEND v9 2/3] fuse: add optional kernel-enforced timeout for requests
Date: Thu, 28 Nov 2024 20:54:55 +0900	[thread overview]
Message-ID: <20241128115455.GG10431@google.com> (raw)
In-Reply-To: <8c5d292f-b343-435f-862e-a98910b6a150@ddn.com>

Cc-ing Tomasz

On (24/11/28 11:23), Bernd Schubert wrote:
> > Thanks for the pointers again, Bernd.
> > 
> >> Miklos had asked for to abort the connection in v4
> >> https://lore.kernel.org/all/CAJfpegsiRNnJx7OAoH58XRq3zujrcXx94S2JACFdgJJ_b8FdHw@mail.gmail.com/raw
> > 
> > OK, sounds reasonable. I'll try to give the series some testing in the
> > coming days.
> > 
> > // I still would probably prefer "seconds" timeout granularity.
> > // Unless this also has been discussed already and Bernd has a link ;)
> 
> 
> The issue is that is currently iterating through 256 hash lists + 
> pending + bg.
> 
> https://lore.kernel.org/all/CAJnrk1b7bfAWWq_pFP=4XH3ddc_9GtAM2mE7EgWnx2Od+UUUjQ@mail.gmail.com/raw

Oh, I see.

> Personally I would prefer a second list to avoid the check spike and latency
> https://lore.kernel.org/linux-fsdevel/9ba4eaf4-b9f0-483f-90e5-9512aded419e@fastmail.fm/raw

That's good to know.  I like the idea of less CPU usage in general,
our devices a battery powered so everything counts, to some extent.

> What is your opinion about that? I guess android and chromium have an
> interest low latencies and avoiding cpu spikes?

Good question.

Can't speak for android, in chromeos we probably will keep it at 1 minute,
but this is because our DEFAULT_HUNG_TASK_TIMEOUT is larger than that (we
use default value of 120 sec). There are setups that might use lower
values, or even re-define default value, e.g.:

arch/arc/configs/axs101_defconfig:CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10
arch/arc/configs/axs103_defconfig:CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10
arch/arc/configs/axs103_smp_defconfig:CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10
arch/arc/configs/hsdk_defconfig:CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10
arch/arc/configs/vdk_hs38_defconfig:CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10
arch/arc/configs/vdk_hs38_smp_defconfig:CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=10
arch/powerpc/configs/mvme5100_defconfig:CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=20

In those cases 1 minute fuse timeout will overshot HUNG_TASK_TIMEOUT
and then the question is whether HUNG_TASK_PANIC is set.

On the other hand, setups that set much lower timeout than
DEFAULT_HUNG_TASK_TIMEOUT=120 will have extra CPU activities regardless,
just because watchdogs will run more often.

Tomasz, any opinions?

  reply	other threads:[~2024-11-28 11:55 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-14 19:13 [PATCH RESEND v9 0/3] fuse: add kernel-enforced request timeout option Joanne Koong
2024-11-14 19:13 ` [PATCH RESEND v9 1/3] fs_parser: add fsparam_u16 helper Joanne Koong
2024-11-14 19:13 ` [PATCH RESEND v9 2/3] fuse: add optional kernel-enforced timeout for requests Joanne Koong
2024-12-06 16:30   ` Etienne Martineau
2024-11-28 10:44   ` Sergey Senozhatsky
2024-11-28 11:00     ` Bernd Schubert
2024-11-28 11:09       ` Sergey Senozhatsky
2024-11-28 11:23         ` Bernd Schubert
2024-11-28 11:54           ` Sergey Senozhatsky [this message]
2024-12-02  9:45             ` Tomasz Figa
2024-12-02 14:43               ` Bernd Schubert
2024-12-02 19:29                 ` Joanne Koong
2024-12-03  4:31                   ` Sergey Senozhatsky
2024-12-03  5:11                     ` Joanne Koong
2024-12-04 14:40                   ` Tomasz Figa
2024-12-04 14:51                     ` Brian Geffon
2024-12-04 15:09                       ` Bernd Schubert
2024-12-05  3:23                       ` Sergey Senozhatsky
2024-12-05 11:07                         ` Brian Geffon
2024-12-03 11:01   ` Sergey Senozhatsky
2024-12-06  0:06     ` Joanne Koong
2024-12-06  4:28       ` Sergey Senozhatsky
2024-12-04 13:14   ` Sergey Senozhatsky
2024-12-05 23:10     ` Joanne Koong
2024-12-04 13:47   ` Sergey Senozhatsky
2024-12-05 23:29     ` Joanne Koong
2024-12-06  3:26       ` Sergey Senozhatsky
2024-12-06  0:37   ` Jeff Layton
2024-12-06 19:19     ` Joanne Koong
2024-12-06 20:06       ` Jeff Layton
2024-12-06 19:05   ` Joanne Koong
2024-12-06 19:56     ` Etienne
2024-12-06 21:52       ` Joanne Koong
2024-12-06 20:12   ` Jeff Layton
2024-12-06 21:54     ` Joanne Koong
2024-11-14 19:13 ` [PATCH RESEND v9 3/3] fuse: add default_request_timeout and max_request_timeout sysctls Joanne Koong
2024-12-06  0:43   ` Jeff Layton
2024-12-06 18:16     ` Joanne Koong
2024-11-21 22:02 ` [PATCH RESEND v9 0/3] fuse: add kernel-enforced request timeout option Josef Bacik

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=20241128115455.GG10431@google.com \
    --to=senozhatsky@chromium.org \
    --cc=bernd.schubert@fastmail.fm \
    --cc=bschubert@ddn.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=joannelkoong@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@meta.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=tfiga@chromium.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 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.