From patchwork Mon Dec 16 23:18:08 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Warren X-Patchwork-Id: 3357361 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7CD42C0D4A for ; Mon, 16 Dec 2013 23:18:15 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9BCC62025A for ; Mon, 16 Dec 2013 23:18:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B47C620251 for ; Mon, 16 Dec 2013 23:18:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751983Ab3LPXSM (ORCPT ); Mon, 16 Dec 2013 18:18:12 -0500 Received: from avon.wwwdotorg.org ([70.85.31.133]:50141 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751725Ab3LPXSM (ORCPT ); Mon, 16 Dec 2013 18:18:12 -0500 Received: from severn.wwwdotorg.org (unknown [192.168.65.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by avon.wwwdotorg.org (Postfix) with ESMTPS id 610C06317; Mon, 16 Dec 2013 16:18:11 -0700 (MST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by severn.wwwdotorg.org (Postfix) with ESMTPSA id 021BEE45FB; Mon, 16 Dec 2013 16:17:54 -0700 (MST) Message-ID: <52AF8A30.9050700@wwwdotorg.org> Date: Mon, 16 Dec 2013 16:18:08 -0700 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Chris Ball , Adrian Hunter CC: "linux-mmc@vger.kernel.org" , "linux-tegra@vger.kernel.org" Subject: Re: max_discard anomaly on certain Sandisk eMMC References: <52AB8DA2.9000001@wwwdotorg.org> In-Reply-To: <52AB8DA2.9000001@wwwdotorg.org> X-Enigmail-Version: 1.5.2 X-Virus-Scanned: clamav-milter 0.97.8 at avon.wwwdotorg.org X-Virus-Status: Clean Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 12/13/2013 03:43 PM, Stephen Warren wrote: > On one of my eMMC devices, I see the following results from calling > mmc_do_calc_max_discard() with various parameters: > > [ 3.057263] MMC_DISCARD_ARG max_discard 1 > [ 3.057266] MMC_ERASE_ARG max_discard 4096 > [ 3.057267] MMC_TRIM_ARG max_discard 1 > > This causes mmc_calc_max_discard() to return 1, which makes the discard > IOCTL extremely slow. Further investigation shows that if I make a few hacks that essentially revert e056a1b5b67b "mmc: queue: let host controllers specify maximum discard timeout": } I end up with: $ cat /sys/.../block/mmcblk1/queue# cat discard_granularity 2097152 $ cat /sys/.../block/mmcblk1/queue# cat discard_max_bytes 2199023255040 $ cat /sys/.../block/mmcblk1/queue# cat discard_zeroes_data 1 With those values, mke2fs is fast, and I validated that "blkdiscard" works; I filled a large partition with /dev/urandom, executed "blkdiscard" on the 4M at the start, and saw zeroes when reading the discarded part back. This implies that the issue is simply the operation of mmc_calc_max_discard(), rather than the eMMC device mis-reporting its discard abilities, doesn't it? --- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c index 357bbc54fe4b..e66af930d0e3 100644 --- a/drivers/mmc/card/queue.c +++ b/drivers/mmc/card/queue.c @@ -167,13 +167,15 @@ static void mmc_queue_setup_discard(struct request_queue *q, return; queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q); - q->limits.max_discard_sectors = max_discard; + q->limits.max_discard_sectors = UINT_MAX; if (card->erased_byte == 0 && !mmc_can_discard(card)) q->limits.discard_zeroes_data = 1; q->limits.discard_granularity = card->pref_erase << 9; /* granularity must not be greater than max. discard */ +#if 0 if (card->pref_erase > max_discard) q->limits.discard_granularity = 0; +#endif if (mmc_can_secure_erase_trim(card)) queue_flag_set_unlocked(QUEUE_FLAG_SECDISCARD, q);