Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755728AbbDUSeq (ORCPT ); Tue, 21 Apr 2015 14:34:46 -0400 Received: from mail-vn0-f41.google.com ([209.85.216.41]:38754 "EHLO mail-vn0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751929AbbDUSem (ORCPT ); Tue, 21 Apr 2015 14:34:42 -0400 MIME-Version: 1.0 In-Reply-To: <55368512.1020503@fb.com> References: <1429636187-30236-1-git-send-email-ming.l@samsung.com> <55368512.1020503@fb.com> Date: Tue, 21 Apr 2015 11:34:41 -0700 Message-ID: Subject: Re: [RFC DRAFT PATCH] per-buffered-write stream IDs From: Ming Lin To: Jens Axboe Cc: Ming Lin , lkml , linux-fsdevel@vger.kernel.org, Dave Chinner , Changho Choi-SSI , "Kwan (Hingkwan) Huen-SSI" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1702 Lines: 43 On Tue, Apr 21, 2015 at 10:12 AM, Jens Axboe wrote: > On 04/21/2015 11:09 AM, Ming Lin wrote: >> >> Hi Jens, >> >> This RFC DRAFT patch is on top of your "[PATCH v2] Support for write >> stream IDs" >> I throw it out early to get comments if it's the way to go. >> >> Quote LWN(http://lwn.net/Articles/638722): >> >> "There would be clear value in a closer association between stream IDs >> and specific buffered-write operations. Getting there would require >> storing >> the stream ID with each dirtied page, though; that, in turn, almost >> certainly >> implies shoehorning the stream ID into the associated page structure. >> That would not be an easy task; it is not surprising that it is not a part >> of >> this patch set. Should the lack of per-buffered-write stream IDs prove to >> be >> a serious constraint in the future, somebody will certainly be motivated >> to >> try to find a place to store another eight bits in struct page." >> >> This draft patch stores stream_id in buffer head instead of page. > > > This is pointless. You need to store it in the page, if the whole point is > that you want this to be trackable. And adding it to struct page would be a > no-go, we can't increase the size of that. See various other discussions > around, for instance, IO priorities for buffered writeback and tracking that > state on the side. I googled, but didn't find related discussions. Could you please point me a link? Thanks. -- 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/