From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: barriers vs. reads Date: Tue, 22 Jun 2004 12:08:28 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622100828.GA12881@suse.de> References: <20040622005302.A1325@almesberger.net> <20040622073919.GV12881@suse.de> <20040622045004.C1325@almesberger.net> <20040622075531.GX12881@suse.de> <20040622053425.E1325@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]:9962 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S261943AbUFVKIb (ORCPT ); Tue, 22 Jun 2004 06:08:31 -0400 To: Werner Almesberger Content-Disposition: inline In-Reply-To: <20040622053425.E1325@almesberger.net> List-Id: linux-fsdevel.vger.kernel.org On Tue, Jun 22 2004, Werner Almesberger wrote: > Jens Axboe wrote: > > If there are lots of barrier writes, you mean? > > If there are a lot of writes before the barrier. Then the reads > after the barrier have to wait for all these writes to complete. > Of course, things get even worse if you have a lot of barriers, > in addition to there being lots of writes. There's nothing you can do about that, in my opinion. Barriers are bad for io scheduler performance, that's a given. > > 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. > > ... which pretty much kills the idea of short predictable > queuing delays :-( So you can't support guarenteed low delays with lots of writes and barriers, big deal. If you need hard guarantees, you need to tailor the environment. IMHO this is no different than the regular linux code base not supporting hard realtime processing. > > Hmm? Recently this was moved into __elv_add_request() > > Ah, okay, different definition of where the elevator starts ;-) > Yes, I saw that. > > BTW, in what cases would ELEVATOR_INSERT_FRONT combined with > a barrier make sense ? It wouldn't really, INSERT_BACK is the only one that really makes sense. But if you do an elv_requeue_request() (ide barrier does this) to reinsert a barrier, it would have the barrier bit set but need to go to the front anyways. SCSI does it too, come to think of it. -- Jens Axboe