From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: barriers vs. reads Date: Tue, 22 Jun 2004 09:55:32 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622075531.GX12881@suse.de> References: <20040622005302.A1325@almesberger.net> <20040622073919.GV12881@suse.de> <20040622045004.C1325@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]:40122 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S261321AbUFVHze (ORCPT ); Tue, 22 Jun 2004 03:55:34 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040622045004.C1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org On Tue, Jun 22 2004, Werner Almesberger wrote: > Jens Axboe wrote: > > I don't think a read-barrier currently has a meaning. A write barrier > > will force ordering for later reads too, of course. > > That's one of the problem spots with priorities: if there are a > lot of writes in the queue, high-priority reads will be delayed > for a long time. If there are lots of barrier writes, you mean? > But do we have cases where reads must not cross write barriers ? To me, it's the expected behaviour. If you issue a barrier write, a read issued later should not be able to fetch old data. > > It can't, the insert position doesn't tell you whether it's a barrier or > > not. You have to check ->flags for that. > > Yet deadline, AS, and CFQ don't do any such check :-) Hmm? Recently this was moved into __elv_add_request() to make sure that a barrier always implies ELEVATOR_INSERT_BACK so these checks were removed. deadline still has it though: /* barriers must flush the reorder queue */ if (unlikely(rq->flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER) && where == ELEVATOR_INSERT_SORT)) where = ELEVATOR_INSERT_BACK; this can be removed now, though. So it's definitely there, if you are using a recent kernel you can assume that INSERT_BACK implies a barrier. -- Jens Axboe