Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757659AbbEEUvU (ORCPT ); Tue, 5 May 2015 16:51:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44194 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753462AbbEEUvR (ORCPT ); Tue, 5 May 2015 16:51:17 -0400 From: Jeff Moyer To: Jens Axboe Cc: , , , Subject: Re: [PATCH v2] Support for write stream IDs References: <1430856181-19568-1-git-send-email-axboe@fb.com> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Tue, 05 May 2015 16:51:11 -0400 In-Reply-To: <1430856181-19568-1-git-send-email-axboe@fb.com> (Jens Axboe's message of "Tue, 5 May 2015 14:02:54 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1677 Lines: 41 Jens Axboe writes: > Hi, > > Changes since the last posting: > > - Added a specific per-file fadvise setting. POSIX_FADV_STREAMID sets > the inode and file stream ID, POSIX_FADV_STREAMID_FILE sets just the > file stream ID. > > - Addressed review comments. > > I've since run some testing with write streams. Test case was a RocksDB > overwrite benchmark, using 3 billion keys of 400B in size (numbers set > use the full size of the device). WAL/LOG was assigned to stream 1, and > each RocksDB compaction level used a separate stream. With streams > enabled, user write to device writes (write amplification) was at 2.33. > Without streams, the write amplification was 3.05. That is roughly 20% > less written NAND, and the streams test subsequently also had 20% > higher throughput. > > Unless there are any grave concerns here, I'd like to merge this for > 4.2. I have a few concerns. You've added POSIX_FADV_* definitions that do not exist in the SUS/POSIX spec. Do we care? We (poor reviewers) still have no idea what the driver side of this will look like. Do streams need to be opened and closed? Is that going to be handled transparently by the kernel, or exposed to userspace? If in the kernel, where in the kernel? You've also added a user-visible api without cc-ing linux-api. My preference would be to wait for the spec to finalize before pushing in changes that depend on it. Cheers, Jeff -- 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/