From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: barriers vs. reads Date: Tue, 22 Jun 2004 09:39:20 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622073919.GV12881@suse.de> References: <20040622005302.A1325@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from ns.virtualhost.dk ([195.184.98.160]:59572 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S261184AbUFVHj2 (ORCPT ); Tue, 22 Jun 2004 03:39:28 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040622005302.A1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org On Tue, Jun 22 2004, Werner Almesberger wrote: > I'm working on an elevator with priorities, and I'm wondering what > semantics are expected from barriers when it comes to reads. > > My problem with read barriers is that they can upset priorities > quite a bit, by forcing the entire queue to be processed before > any new (possibly timing-critical) reads are allowed. > > So, is there anything that actually depends on barriers also > constraining read - or, more likely, read vs. write - order ? > If not, will there be ? I don't think a read-barrier currently has a meaning. A write barrier will force ordering for later reads too, of course. > Also, it seems, but is never quite explicitly spelt out, that an > elevator is never really supposed to look for barriers in > rq->flags, but can solely rely on the insertion position as an > indication for barriers. Is this true ? It can't, the insert position doesn't tell you whether it's a barrier or not. You have to check ->flags for that. -- Jens Axboe