Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751870AbbEGTTz (ORCPT ); Thu, 7 May 2015 15:19:55 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:46745 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbbEGTTu (ORCPT ); Thu, 7 May 2015 15:19:50 -0400 To: Jens Axboe Cc: "Martin K. Petersen" , Jeff Moyer , , , , Subject: Re: [PATCH v2] Support for write stream IDs From: "Martin K. Petersen" Organization: Oracle Corporation References: <1430856181-19568-1-git-send-email-axboe@fb.com> <55493097.6040007@fb.com> <55493AC1.9090408@fb.com> <554A4DB7.7070202@fb.com> Date: Thu, 07 May 2015 15:19:24 -0400 In-Reply-To: <554A4DB7.7070202@fb.com> (Jens Axboe's message of "Wed, 6 May 2015 11:21:59 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3303 Lines: 70 >>>>> "Jens" == Jens Axboe writes: Jens> This wont solve the problem of devices having too few streams. But Jens> it'll work regardless, we'll just have to push them separately to Jens> do that. It's not an easy problem for them either, resource Jens> constraints on the device side could exclude supporting as many Jens> streams as we would ideally want. But they already have to manage *every* other resource that way: Read cache, write cache, flash channels, open zones on ZAC/ZBC. If they run out of memory and have to internally close one stream context to open another that's their business. If the concurrent ID count is low, performance their particular widgets is going to suck for some applications and people will avoid them. Boo hoo. I'm super happy the SSD industry (well, the market) came to its senses and abolished all the outrageous demands put on the I/O stack to overcome erase block size and write amplification issues. Now all that's a solved problem and we can move on. Next problem child was the host managed zoned disk madness. Yet another device implementation headache that suddenly requires us to reinvent filesystems and the entire I/O stack. Next in the pipeline is the stream ID stuff. Which once again puts the burden on us to overcome device implementation issues and misunderstands how operating systems work. There are two fundamental problems: - The standards are developed by device vendors with little to no input from the OS vendors - The standards proposals are written, edited, and declared complete before anybody actually tries to implement them That's how we end up with all these lame duck spec extensions that are device implementation-specific and impossible to use generically. I scream as loudly as I can. But I am but one voice in a sea of device vendors. And unless we Linux developers start pushing back in unison we'll end up in a quagmire of epic proportions. Jens> In some ways I get it, you have to start somewhere. The current Jens> proposal is useful for _some_ cases, it's not great for Jens> everything. As long as it can be expanded to support as many Jens> streams as we would want, then it would work. It's (again) a bit Jens> of a chicken and egg problem. We need to make some progress, or Jens> the whole thing is going to go away. And I think that'd be a Jens> shame, since there's definitely merit to passing these lifetime Jens> hints to the device. The problem is that once these things end up in the standards, the CDB fields are gone. And if the clunky intermediate stuff is "good enough" then the motivation to fix things properly goes away. There are many, many reasons why stream IDs are a good thing. Above and beyond what the current proposals want. The notion of tagging is a much better abstraction than bootiness and guessing a percentage for how sequential future accesses might be. It's a simple, clean interface that the device--regardless of media type and implementation--can benefit from. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/