From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752643AbdEAQUS (ORCPT ); Mon, 1 May 2017 12:20:18 -0400 Received: from g4t3425.houston.hpe.com ([15.241.140.78]:54116 "EHLO g4t3425.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbdEAQUO (ORCPT ); Mon, 1 May 2017 12:20:14 -0400 From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" CC: "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "dave.jiang@intel.com" , "vishal.l.verma@intel.com" Subject: Re: [PATCH] libnvdimm: rework region badblocks clearing Thread-Topic: [PATCH] libnvdimm: rework region badblocks clearing Thread-Index: AQHSwa+nta9I7uFKMkmISr7SDbaEM6HfnXuAgAACnoCAAAJeAIAABYqAgAABTYCAAADqgA== Date: Mon, 1 May 2017 16:20:09 +0000 Message-ID: <1493655607.30303.19.camel@hpe.com> References: <149355594185.9917.1577772489949690281.stgit@dwillia2-desk3.amr.corp.intel.com> <1493652871.30303.15.camel@hpe.com> <1493655131.30303.17.camel@hpe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [15.219.163.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AT5PR84MB0260;7:xMHMoDGbnSuR1hJ4SuMJPGzd6I7TvbqFUpU1b/qwzRGzaxQG0zFrh5IFFzpitecDgK93VsZc4DpNyUFJYt3k6YtpJYxwe3kWJNvBIEc7DSJNywjgOcCgsGrUmdmZlKMpHeg1clz4GFkyre1lMBls326WbDPBOnWevSjRFZfyzBpOy68vGCfZqFxKpemvaRx4LFjUtIidVAcAjGtwUZfEWw3XEF25SMB41CFVqe12pCfkvjao62dQNGhQZfgSM/0lCh1vrQESmbo3JSf2SEvu89mpFBcmSgI5qe6Eb7TSHCjeOZwcr/Ugm8Msb0/uQh4ZajLcWis+PZKSTODRDr3P3Q== x-ms-office365-filtering-correlation-id: 16b66297-1569-4d62-225f-08d490adf012 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:AT5PR84MB0260; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(6072148);SRVR:AT5PR84MB0260;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0260; x-forefront-prvs: 02945962BD x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39840400002)(39400400002)(39450400003)(39850400002)(39860400002)(377454003)(24454002)(377424004)(77096006)(33646002)(25786009)(6486002)(6436002)(53546009)(5660300001)(305945005)(122556002)(54356999)(189998001)(76176999)(4326008)(36756003)(6506006)(7736002)(50986999)(93886004)(229853002)(2351001)(103116003)(54906002)(6512007)(3280700002)(2906002)(53936002)(6116002)(478600001)(102836003)(3846002)(3660700001)(2501003)(6916009)(86362001)(110136004)(2900100001)(2950100002)(8936002)(8676002)(5640700003)(81166006)(38730400002);DIR:OUT;SFP:1102;SCL:1;SRVR:AT5PR84MB0260;H:AT5PR84MB0260.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <256BAA58D087B34D9A286B1DECBB8088@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2017 16:20:09.6294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0260 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v41GKRq6003545 On Mon, 2017-05-01 at 09:16 -0700, Dan Williams wrote: > On Mon, May 1, 2017 at 9:12 AM, Kani, Toshimitsu > wrote: > > On Mon, 2017-05-01 at 08:52 -0700, Dan Williams wrote: > > > On Mon, May 1, 2017 at 8:43 AM, Dan Williams > > l.co > > > m> wrote: > > > > On Mon, May 1, 2017 at 8:34 AM, Kani, Toshimitsu > > > e.co > > > > m> wrote: > > > > > On Sun, 2017-04-30 at 05:39 -0700, Dan Williams wrote: > > > >  : > > > > > > > > > > Hi Dan, > > > > > > > > > > I was testing the change with CONFIG_DEBUG_ATOMIC_SLEEP set > > > > > this time, and hit the following BUG with BTT.  This is a > > > > > separate issue (not introduced by this patch), but it shows > > > > > that we have an issue with the DSM call path as well. > > > > > > > > Ah, great find, thanks! We don't see this in the unit tests > > > > because the nfit_test infrastructure takes no sleeping actions > > > > in its simulated DSM path. Outside of converting btt to use > > > > sleeping locks I'm not sure I see a path forward. I wonder how > > > > bad the performance impact of that would be? Perhaps with > > > > opportunistic spinning it won't be so bad, but I don't see > > > > another choice. > > > > > > It's worse than that. Part of the performance optimization of BTT > > > I/O was to avoid locking altogether when we could rely on a BTT > > > lane percpu, so that would also need to be removed. > > > > I do not have a good idea either, but I'd rather disable this > > clearing in the regular BTT write path than adding sleeping locks > > to BTT. Clearing a bad block in the BTT write path is > > difficult/challenging since it allocates a new block. > > Actually, that may make things easier. Can we teach BTT to track > error blocks and clear them before they are reassigned? I was thinking the same after sending it. I think we should be able to do that. Thanks, -Toshi