From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752294AbbGNPCa (ORCPT ); Tue, 14 Jul 2015 11:02:30 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:52280 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751627AbbGNPC3 (ORCPT ); Tue, 14 Jul 2015 11:02:29 -0400 From: Jens Axboe To: CC: , Subject: [PATCH 0/2] Configurable max discard size Date: Tue, 14 Jul 2015 09:02:17 -0600 Message-ID: <1436886139-18673-1-git-send-email-axboe@fb.com> X-Mailer: git-send-email 2.4.1.168.g1ea28e1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-14_07:2015-07-14,2015-07-14,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Most drivers use UINT_MAX (or some variant thereof) for max discard size, since they don't have a real limit for a non-data transferring command. This is fine from a throughput point of view, but for a lot of devices (all?), it truly sucks on latency. We've seen cases of hundreds of msec in latencies for reads/writes when deleting files on an fs with discard enabled. For the problematic devices that we have tested, artificially limiting the size of the discards issued brings it down to a more manageable 1-2ms max latencies.