From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Jerome Marchand <jmarchan@redhat.com>,
linux-nvdimm@lists.01.org, Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Minchan Kim <minchan@kernel.org>,
seungho1.park@lge.com, Jan Kara <jack@suse.cz>,
"karam . lee" <karam.lee@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Nitin Gupta <ngupta@vflare.org>
Subject: Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt
Date: Wed, 2 Aug 2017 16:13:59 -0600 [thread overview]
Message-ID: <20170802221359.GA20666@linux.intel.com> (raw)
In-Reply-To: <20170728173143.GE15980@bombadil.infradead.org>
On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote:
> On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote:
> > Dan Williams and Christoph Hellwig have recently expressed doubt about
> > whether the rw_page() interface made sense for synchronous memory drivers
> > [1][2]. It's unclear whether this interface has any performance benefit
> > for these drivers, but as we continue to fix bugs it is clear that it does
> > have a maintenance burden. This series removes the rw_page()
> > implementations in brd, pmem and btt to relieve this burden.
>
> Why don't you measure whether it has performance benefits? I don't
> understand why zram would see performance benefits and not other drivers.
> If it's going to be removed, then the whole interface should be removed,
> not just have the implementations removed from some drivers.
Okay, I've run a bunch of performance tests with the PMEM and with BTT entry
points for rw_pages() in a swap workload, and in all cases I do see an
improvement over the code when rw_pages() is removed. Here are the results
from my random lab box:
Average latency of swap_writepage()
+------+------------+---------+-------------+
| | no rw_page | rw_page | Improvement |
+-------------------------------------------+
| PMEM | 5.0 us | 4.7 us | 6% |
+-------------------------------------------+
| BTT | 6.8 us | 6.1 us | 10% |
+------+------------+---------+-------------+
Average latency of swap_readpage()
+------+------------+---------+-------------+
| | no rw_page | rw_page | Improvement |
+-------------------------------------------+
| PMEM | 3.3 us | 2.9 us | 12% |
+-------------------------------------------+
| BTT | 3.7 us | 3.4 us | 8% |
+------+------------+---------+-------------+
The workload was pmbench, a memory benchmark, run on a system where I had
severely restricted the amount of memory in the system with the 'mem' kernel
command line parameter. The benchmark was set up to test more memory than I
allowed the OS to have so it spilled over into swap.
The PMEM or BTT device was set up as my swap device, and during the test I got
a few hundred thousand samples of each of swap_writepage() and
swap_writepage(). The PMEM/BTT device was just memory reserved with the
memmap kernel command line parameter.
Thanks, Matthew, for asking for performance data. It looks like removing this
code would have been a mistake.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, "karam . lee" <karam.lee@lge.com>,
Minchan Kim <minchan@kernel.org>,
Jerome Marchand <jmarchan@redhat.com>,
Nitin Gupta <ngupta@vflare.org>,
seungho1.park@lge.com, Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
Jens Axboe <axboe@kernel.dk>,
Vishal Verma <vishal.l.verma@intel.com>,
linux-nvdimm@lists.01.org
Subject: Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt
Date: Wed, 2 Aug 2017 16:13:59 -0600 [thread overview]
Message-ID: <20170802221359.GA20666@linux.intel.com> (raw)
In-Reply-To: <20170728173143.GE15980@bombadil.infradead.org>
On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote:
> On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote:
> > Dan Williams and Christoph Hellwig have recently expressed doubt about
> > whether the rw_page() interface made sense for synchronous memory drivers
> > [1][2]. It's unclear whether this interface has any performance benefit
> > for these drivers, but as we continue to fix bugs it is clear that it does
> > have a maintenance burden. This series removes the rw_page()
> > implementations in brd, pmem and btt to relieve this burden.
>
> Why don't you measure whether it has performance benefits? I don't
> understand why zram would see performance benefits and not other drivers.
> If it's going to be removed, then the whole interface should be removed,
> not just have the implementations removed from some drivers.
Okay, I've run a bunch of performance tests with the PMEM and with BTT entry
points for rw_pages() in a swap workload, and in all cases I do see an
improvement over the code when rw_pages() is removed. Here are the results
from my random lab box:
Average latency of swap_writepage()
+------+------------+---------+-------------+
| | no rw_page | rw_page | Improvement |
+-------------------------------------------+
| PMEM | 5.0 us | 4.7 us | 6% |
+-------------------------------------------+
| BTT | 6.8 us | 6.1 us | 10% |
+------+------------+---------+-------------+
Average latency of swap_readpage()
+------+------------+---------+-------------+
| | no rw_page | rw_page | Improvement |
+-------------------------------------------+
| PMEM | 3.3 us | 2.9 us | 12% |
+-------------------------------------------+
| BTT | 3.7 us | 3.4 us | 8% |
+------+------------+---------+-------------+
The workload was pmbench, a memory benchmark, run on a system where I had
severely restricted the amount of memory in the system with the 'mem' kernel
command line parameter. The benchmark was set up to test more memory than I
allowed the OS to have so it spilled over into swap.
The PMEM or BTT device was set up as my swap device, and during the test I got
a few hundred thousand samples of each of swap_writepage() and
swap_writepage(). The PMEM/BTT device was just memory reserved with the
memmap kernel command line parameter.
Thanks, Matthew, for asking for performance data. It looks like removing this
code would have been a mistake.
next prev parent reply other threads:[~2017-08-02 22:11 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 16:56 [PATCH 0/3] remove rw_page() from brd, pmem and btt Ross Zwisler
2017-07-28 16:56 ` Ross Zwisler
2017-07-28 16:56 ` [PATCH 1/3] btt: remove btt_rw_page() Ross Zwisler
2017-07-28 16:56 ` Ross Zwisler
2017-08-03 16:15 ` kbuild test robot
2017-08-03 16:15 ` kbuild test robot
2017-07-28 16:56 ` [PATCH 2/3] pmem: remove pmem_rw_page() Ross Zwisler
2017-07-28 16:56 ` Ross Zwisler
2017-07-28 16:56 ` [PATCH 3/3] brd: remove brd_rw_page() Ross Zwisler
2017-07-28 16:56 ` Ross Zwisler
2017-07-28 17:31 ` [PATCH 0/3] remove rw_page() from brd, pmem and btt Matthew Wilcox
2017-07-28 17:31 ` Matthew Wilcox
2017-07-28 21:21 ` Andrew Morton
2017-07-28 21:21 ` Andrew Morton
2017-07-30 22:16 ` Minchan Kim
2017-07-30 22:16 ` Minchan Kim
2017-07-30 22:38 ` Minchan Kim
2017-07-30 22:38 ` Minchan Kim
2017-07-31 7:17 ` Christoph Hellwig
2017-07-31 7:17 ` Christoph Hellwig
2017-07-31 7:36 ` Minchan Kim
2017-07-31 7:36 ` Minchan Kim
2017-07-31 7:42 ` Christoph Hellwig
2017-07-31 7:42 ` Christoph Hellwig
2017-07-31 7:44 ` Christoph Hellwig
2017-07-31 7:44 ` Christoph Hellwig
2017-08-01 6:23 ` Minchan Kim
2017-08-01 6:23 ` Minchan Kim
2017-08-02 22:13 ` Ross Zwisler [this message]
2017-08-02 22:13 ` Ross Zwisler
2017-08-03 0:13 ` Minchan Kim
2017-08-03 0:13 ` Minchan Kim
2017-08-03 0:34 ` Dan Williams
2017-08-03 0:34 ` Dan Williams
2017-08-03 8:05 ` Christoph Hellwig
2017-08-03 8:05 ` Christoph Hellwig
2017-08-04 0:57 ` Minchan Kim
2017-08-04 0:57 ` Minchan Kim
2017-08-03 21:13 ` Ross Zwisler
2017-08-03 21:13 ` Ross Zwisler
2017-08-03 21:17 ` Jens Axboe
2017-08-03 21:17 ` Jens Axboe
2017-08-04 3:54 ` Minchan Kim
2017-08-04 3:54 ` Minchan Kim
2017-08-04 8:17 ` Minchan Kim
2017-08-04 8:17 ` Minchan Kim
2017-08-04 18:01 ` Dan Williams
2017-08-04 18:01 ` Dan Williams
2017-08-04 18:21 ` Ross Zwisler
2017-08-04 18:21 ` Ross Zwisler
2017-08-04 18:24 ` Dan Williams
2017-08-04 18:24 ` Dan Williams
2017-08-07 8:23 ` Minchan Kim
2017-08-07 8:23 ` Minchan Kim
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=20170802221359.GA20666@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jmarchan@redhat.com \
--cc=karam.lee@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=seungho1.park@lge.com \
--cc=willy@infradead.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.