From patchwork Fri Feb 22 18:20:08 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 10826815 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 67987184E for ; Fri, 22 Feb 2019 18:20:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5535632680 for ; Fri, 22 Feb 2019 18:20:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 49AB032A88; Fri, 22 Feb 2019 18:20:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0296232676 for ; Fri, 22 Feb 2019 18:20:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726902AbfBVSUQ (ORCPT ); Fri, 22 Feb 2019 13:20:16 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:52222 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726246AbfBVSUQ (ORCPT ); Fri, 22 Feb 2019 13:20:16 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1MI4DQL027885; Fri, 22 Feb 2019 18:20:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : mime-version : content-type; s=corp-2018-07-02; bh=S5rIGstDMj3MeCfrkJOspVebxB47wGLVkaoUYTDd74E=; b=LTIwtKd+0uwGVZpT3OOp73mQW3VoDls0DBab4TpyK3VyUQcScTkN6hqTZrASeELkZmGM FTEEITDIUucBKNG2lgaeb1k8hNNbQ2Z4LY8Aza8IXiGFGTvoPcx+0VLsww19d9PLh3+Z K+8XW0AY6xXzeTnRXIyoHoYI3cMXMGNnUdLVtkwq5oerSoco3/uMu3PPit7R1u0GjpZb bi4Ui9J2j5vf/v4KGU1UiiA5dOOyCIUIEINFukTkR/U42wuQrZpochTHzL0E1vnfD//z iOGdfgApUiVctagYfazzUVZ4fe1LLVA0929CkBAYKap3mo7JnJz21F4Du6d7wrDW9T9M 6g== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2qp9xugsr8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Feb 2019 18:20:10 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x1MIK9cg009453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Feb 2019 18:20:09 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1MIK8UN012423; Fri, 22 Feb 2019 18:20:08 GMT Received: from localhost (/10.159.254.125) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Feb 2019 10:20:08 -0800 Date: Fri, 22 Feb 2019 10:20:08 -0800 From: "Darrick J. Wong" To: dan.j.williams@intel.com Cc: linux-nvdimm@lists.01.org, zwisler@kernel.org, vishal.l.verma@intel.com, xfs , linux-fsdevel Subject: [RFC PATCH] pmem: advertise page alignment for pmem devices supporting fsdax Message-ID: <20190222182008.GT6503@magnolia> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9175 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902220124 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all! Uh, we have an internal customer who's been trying out MAP_SYNC on pmem, and they've observed that one has to do a fair amount of legwork (in the form of mkfs.xfs parameters) to get the kernel to set up 2M PMD mappings. They (of course) want to mmap hundreds of GB of pmem, so the PMD mappings are much more efficient. I started poking around w.r.t. what mkfs.xfs was doing and realized that if the fsdax pmem device advertised iomin/ioopt of 2MB, then mkfs will set up all the parameters automatically. Below is my ham-handed attempt to teach the kernel to do this. Comments, flames, "WTF is this guy smoking?" are all welcome. :) --D --- Configure pmem devices to advertise the default page alignment when said block device supports fsdax. Certain filesystems use these iomin/ioopt hints to try to create aligned file extents, which makes it much easier for mmaps to take advantage of huge page table entries. Signed-off-by: Darrick J. Wong --- drivers/nvdimm/pmem.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index bc2f700feef8..3eeb9dd117d5 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -441,8 +441,11 @@ static int pmem_attach_disk(struct device *dev, blk_queue_logical_block_size(q, pmem_sector_size(ndns)); blk_queue_max_hw_sectors(q, UINT_MAX); blk_queue_flag_set(QUEUE_FLAG_NONROT, q); - if (pmem->pfn_flags & PFN_MAP) + if (pmem->pfn_flags & PFN_MAP) { blk_queue_flag_set(QUEUE_FLAG_DAX, q); + blk_queue_io_min(q, PFN_DEFAULT_ALIGNMENT); + blk_queue_io_opt(q, PFN_DEFAULT_ALIGNMENT); + } q->queuedata = pmem; disk = alloc_disk_node(0, nid);