public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [mm/page]  ab19939a6a: ltp.msync04.fail
Date: Mon, 13 Sep 2021 10:11:22 +0200	[thread overview]
Message-ID: <YT8HqsXsHFeMdDxS@yuki> (raw)
In-Reply-To: <20210912123429.GA25450@xsang-OptiPlex-9020>

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.

-- 
Cyril Hrubis
chrubis@suse.cz

WARNING: multiple messages have this Message-ID (diff)
From: Cyril Hrubis <chrubis@suse.cz>
To: kernel test robot <oliver.sang@intel.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>, 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, 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 10:11:22 +0200	[thread overview]
Message-ID: <YT8HqsXsHFeMdDxS@yuki> (raw)
Message-ID: <20210913081122.cgo1XsREb9ECPB2CeJPcrTLICQHkoEdNg_jZwC-uZYQ@z> (raw)
In-Reply-To: <20210912123429.GA25450@xsang-OptiPlex-9020>

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.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2021-09-13  8:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-12 12:34 [LTP] [mm/page] ab19939a6a: ltp.msync04.fail kernel test robot
2021-09-13  8:11 ` Cyril Hrubis [this message]
2021-09-13  8:11   ` Cyril Hrubis
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
2022-01-25  9:27     ` Richard Palethorpe
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=YT8HqsXsHFeMdDxS@yuki \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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