Date: Fri, 5 Jan 2007 01:53:22 -0800 (PST) From: "R. B. Riddick" <arne_woerner@yahoo.com> To: lulf@stud.ntnu.no, freebsd-geom@freebsd.org, freebsd-current@freebsd.org Subject: Re: Pluggable Disk Schedulers in GEOM Message-ID: <703692.97797.qm@web30301.mail.mud.yahoo.com> In-Reply-To: <20070105015800.s3rqdzgm8k8owk4s@webmail.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--- lulf@stud.ntnu.no wrote: > for I/O. Then I would extract out the default I/O scheduler and try out some > other ways to schedule I/O. Also, I'm not sure how I would handle each > schedulers way to organize the queue. One should allow for different types > of bioq's for the schedulers since they may have different needs of > organizing queues (like a heap maybe). > I would _guess_ for features like in TCQ (Tagged Command Queuing) or NCQ (Native Command Queuing) the g_down thread is the wrong place, because: It would need knowledge about the underlying GEOM device, so that it can determine the correct moment to start a certain read request (currently g_down (g_io_schedule_down in src/sys/geom/geom_io.c) sees most likely just one request in its queue before it goes to sleep again, so that reordering this single one request would make no sense; if one delays read request this might lead to worse performance than before, because the disk handles simultaneous read requests better). For write requests this (TCQ/NCQ related scheduling) might be easier, because they can be delayed and delivered back up (g_up) early (I did that in graid5). A further enhancement might be the combination of requests (e.g. if they overlap or if they (nearly) adjoin to each other), which could be done in g_down, too (I do that in graid5, which leaded to a lot of bcopy-activity). -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?703692.97797.qm>