From mboxrd@z Thu Jan 1 00:00:00 1970 From: Werner Almesberger Subject: Re: barriers vs. reads Date: Tue, 22 Jun 2004 05:34:25 -0300 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040622053425.E1325@almesberger.net> References: <20040622005302.A1325@almesberger.net> <20040622073919.GV12881@suse.de> <20040622045004.C1325@almesberger.net> <20040622075531.GX12881@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from almesberger.net ([63.105.73.238]:12810 "EHLO host.almesberger.net") by vger.kernel.org with ESMTP id S261389AbUFVIeb (ORCPT ); Tue, 22 Jun 2004 04:34:31 -0400 To: Jens Axboe Content-Disposition: inline In-Reply-To: <20040622075531.GX12881@suse.de>; from axboe@suse.de on Tue, Jun 22, 2004 at 09:55:32AM +0200 List-Id: linux-fsdevel.vger.kernel.org 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. > 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 :-( > 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 ? - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/