From: Miklos Szeredi <mszeredi@redhat.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: kernel test robot <oliver.sang@intel.com>,
Chi Wu <wuchi.zero@gmail.com>, Jan Kara <jack@suse.cz>,
lkp@intel.com, lkp@lists.01.org,
LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@fb.com>,
Sedat Dilek <sedat.dilek@gmail.com>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
ltp@lists.linux.it
Subject: Re: [LTP] [mm/page] ab19939a6a: ltp.msync04.fail
Date: Mon, 13 Sep 2021 16:59:51 +0200 [thread overview]
Message-ID: <CAOssrKdQ0XWqk1nbpRjRAO7E+t5+7qzXm1mkJPObkzsQrbAoKg@mail.gmail.com> (raw)
In-Reply-To: <YT8HqsXsHFeMdDxS@yuki>
On Mon, Sep 13, 2021 at 10:19 AM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: ab19939a6a5010cba4e9cb04dd8bee03c72edcbd ("mm/page-writeback: Fix performance when BDI's share of ratio is 0.")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> >
> > in testcase: ltp
> > version: ltp-x86_64-14c1f76-1_20210907
> > with following parameters:
> >
> > disk: 1HDD
> > fs: xfs
> > test: syscalls-03
> > ucode: 0xe2
> >
> > test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
> > test-url: http://linux-test-project.github.io/
>
> The msync04 test formats a device with a diffrent filesystems, for each
> filesystem it maps a file, writes to the mapped page and the checks a
> dirty bit in /proc/kpageflags before and after msync() on that page.
>
> This seems to be broken after this patch for ntfs over FUSE and it looks
> like the page does not have a dirty bit set right after it has been
> written to.
>
> Also I guess that we should increase the number of the pages we dirty or
> attempt to retry since a single page may be flushed to the storage if we
> are unlucky and the process is preempted between the write and the
> initial check for the dirty bit.
Weird. Does this reproduce 100% of the time? If not, then I guess
it's a race and we can ignore this report (or improve the test to make
it less likely to trigger).
Thanks,
Miklos
WARNING: multiple messages have this Message-ID (diff)
From: Miklos Szeredi <mszeredi@redhat.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Jan Kara <jack@suse.cz>,
lkp@intel.com, Chi Wu <wuchi.zero@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@fb.com>,
lkp@lists.01.org, kernel test robot <oliver.sang@intel.com>,
Sedat Dilek <sedat.dilek@gmail.com>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
ltp@lists.linux.it
Subject: Re: [LTP] [mm/page] ab19939a6a: ltp.msync04.fail
Date: Mon, 13 Sep 2021 16:59:51 +0200 [thread overview]
Message-ID: <CAOssrKdQ0XWqk1nbpRjRAO7E+t5+7qzXm1mkJPObkzsQrbAoKg@mail.gmail.com> (raw)
Message-ID: <20210913145951.r6biKrUcqaiT-XDWduk8B-v5xXw3fKa1TqbL7kNgEsI@z> (raw)
In-Reply-To: <YT8HqsXsHFeMdDxS@yuki>
On Mon, Sep 13, 2021 at 10:19 AM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: ab19939a6a5010cba4e9cb04dd8bee03c72edcbd ("mm/page-writeback: Fix performance when BDI's share of ratio is 0.")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> >
> > in testcase: ltp
> > version: ltp-x86_64-14c1f76-1_20210907
> > with following parameters:
> >
> > disk: 1HDD
> > fs: xfs
> > test: syscalls-03
> > ucode: 0xe2
> >
> > test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
> > test-url: http://linux-test-project.github.io/
>
> The msync04 test formats a device with a diffrent filesystems, for each
> filesystem it maps a file, writes to the mapped page and the checks a
> dirty bit in /proc/kpageflags before and after msync() on that page.
>
> This seems to be broken after this patch for ntfs over FUSE and it looks
> like the page does not have a dirty bit set right after it has been
> written to.
>
> Also I guess that we should increase the number of the pages we dirty or
> attempt to retry since a single page may be flushed to the storage if we
> are unlucky and the process is preempted between the write and the
> initial check for the dirty bit.
Weird. Does this reproduce 100% of the time? If not, then I guess
it's a race and we can ignore this report (or improve the test to make
it less likely to trigger).
Thanks,
Miklos
--
Mailing list info: https://lists.linux.it/listinfo/ltp
WARNING: multiple messages have this Message-ID (diff)
From: Miklos Szeredi <mszeredi@redhat.com>
To: lkp@lists.01.org
Subject: Re: [LTP] [mm/page] ab19939a6a: ltp.msync04.fail
Date: Mon, 13 Sep 2021 16:59:51 +0200 [thread overview]
Message-ID: <CAOssrKdQ0XWqk1nbpRjRAO7E+t5+7qzXm1mkJPObkzsQrbAoKg@mail.gmail.com> (raw)
In-Reply-To: <YT8HqsXsHFeMdDxS@yuki>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Mon, Sep 13, 2021 at 10:19 AM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: ab19939a6a5010cba4e9cb04dd8bee03c72edcbd ("mm/page-writeback: Fix performance when BDI's share of ratio is 0.")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> >
> > in testcase: ltp
> > version: ltp-x86_64-14c1f76-1_20210907
> > with following parameters:
> >
> > disk: 1HDD
> > fs: xfs
> > test: syscalls-03
> > ucode: 0xe2
> >
> > test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
> > test-url: http://linux-test-project.github.io/
>
> The msync04 test formats a device with a diffrent filesystems, for each
> filesystem it maps a file, writes to the mapped page and the checks a
> dirty bit in /proc/kpageflags before and after msync() on that page.
>
> This seems to be broken after this patch for ntfs over FUSE and it looks
> like the page does not have a dirty bit set right after it has been
> written to.
>
> Also I guess that we should increase the number of the pages we dirty or
> attempt to retry since a single page may be flushed to the storage if we
> are unlucky and the process is preempted between the write and the
> initial check for the dirty bit.
Weird. Does this reproduce 100% of the time? If not, then I guess
it's a race and we can ignore this report (or improve the test to make
it less likely to trigger).
Thanks,
Miklos
next prev parent reply other threads:[~2021-09-13 15:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-12 12:34 [mm/page] ab19939a6a: ltp.msync04.fail kernel test robot
2021-09-12 12:34 ` kernel test robot
2021-09-12 12:34 ` [LTP] " kernel test robot
2021-09-13 8:11 ` Cyril Hrubis
2021-09-13 8:11 ` Cyril Hrubis
2021-09-13 8:11 ` Cyril Hrubis
2021-09-13 14:59 ` Miklos Szeredi [this message]
2021-09-13 14:59 ` Miklos Szeredi
2021-09-13 14:59 ` Miklos Szeredi
2021-09-17 12:13 ` Jan Kara
2021-09-17 12:13 ` Jan Kara
2021-09-17 12:13 ` Jan Kara
2022-01-25 9:27 ` Richard Palethorpe
2022-01-25 9:27 ` Richard Palethorpe
2022-01-25 9:27 ` Richard Palethorpe
2022-01-25 12:17 ` Jan Kara
2022-01-25 12:17 ` Jan Kara
2022-01-25 12:17 ` Jan Kara
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=CAOssrKdQ0XWqk1nbpRjRAO7E+t5+7qzXm1mkJPObkzsQrbAoKg@mail.gmail.com \
--to=mszeredi@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@fb.com \
--cc=chrubis@suse.cz \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=ltp@lists.linux.it \
--cc=oliver.sang@intel.com \
--cc=sedat.dilek@gmail.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wuchi.zero@gmail.com \
/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.