Messages in this thread | | | Date | Tue, 21 Apr 2015 13:05:30 -0600 | From | Jens Axboe <> | Subject | Re: [RFC DRAFT PATCH] per-buffered-write stream IDs |
| |
On 04/21/2015 12:34 PM, Ming Lin wrote: > On Tue, Apr 21, 2015 at 10:12 AM, Jens Axboe <axboe@fb.com> 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?
This is the most recent effort:
https://lwn.net/Articles/628631/
My point is that adding it to the buffer_head accomplishes nothing. You need to track from when the page was dirtied.
-- Jens Axboe
| |