Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Jan 2007 10:34:17 -0800
From:      Luigi Rizzo <rizzo@icir.org>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        freebsd-current@freebsd.org, lulf@stud.ntnu.no, freebsd-geom@freebsd.org
Subject:   Re: Pluggable Disk Schedulers in GEOM
Message-ID:  <20070105103417.B91349@xorpc.icir.org>
In-Reply-To: <20070105140941.B98541@fledge.watson.org>; from rwatson@freebsd.org on Fri, Jan 05, 2007 at 02:14:26PM %2B0000
References:  <20070105015800.s3rqdzgm8k8owk4s@webmail.ntnu.no> <20070105140941.B98541@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 05, 2007 at 02:14:26PM +0000, Robert Watson wrote:
> 
> On Fri, 5 Jan 2007, lulf@stud.ntnu.no wrote:
> 
> > Anyway, I'd like to research a bit on this topic to just see how much it 
> > does matter with different I/O scheduling for different purposes.
> 
> I think working on this is interesting, but the one caution I'd have is that 
> it's possibly to introduce serious priority inversions through any complex 
> scheduling scheme for I/O.  In our VFS, I/O is frequently performed while 
> holding locks or things that act like locks -- for example, during a directory 
> lookup, while pulling an inode off the disk, etc.  The I/O will be initiated 
> by one thread, but then other threads will end up waiting for it also.  If 
> there is a naive mapping of initiating thread priority to I/O request 
> priority, then you can end up with high priority threads being blocked on a 
> low priority tasks, leading to nasty starvation effects, especially if the 
> scheduler allows indefinite waiting for I/O at a low priority.  This, at a 

that's a problem with priority based schedulers. neither the elevator
nor the proportional-fair scheduler in Hybrid, nor a plain FIFO scheduler
soffer from this 'indefinite waiting' problem.
If i remember well the elevator code in freebsd had some support
for 'prioritized' requests that could go in front of the queue no
matter what, but i think that part was not really used.

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070105103417.B91349>