Date: Fri, 14 Dec 2001 15:31:51 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Kirk McKusick <mckusick@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: RE: cvs commit: src/sys/kern subr_disklabel.c Message-ID: <XFMail.011214153151.jhb@FreeBSD.org> In-Reply-To: <200112140550.fBE5oiD51625@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14-Dec-01 Kirk McKusick wrote:
> mckusick 2001/12/13 21:50:44 PST
>
> Modified files:
> sys/kern subr_disklabel.c
> Log:
> Add disk I/O scheduling for positively niced processes.
> When a positively niced process requests a disk I/O, make
> it wait for its nice value of ticks before scheduling its
> I/O request if there are any other processes with I/O
> requests in the disk queue. For all the gory details, see
> the ``Running fsck in the Background'' paper in the Usenix
> BSDCon 2002 Conference Proceedings, pages 55-64.
Is this a bug:
if (td && td->td_ksegrp->kg_nice > 0) {
TAILQ_FOREACH(bn, &bioq->queue, bio_queue)
if (BIOTOBUF(bn)->b_vp != BIOTOBUF(bn)->b_vp)
break;
It looks like one of those 'bn's in the if should be a 'bp'. Also, you don't
seem to be using the dksort_mtx to protect anything. You can just call
tsleep() with your timeout in this case. You don't need the lock.
Also, pardon my ignorance, but why not use a separate queue for I/O's from
niced processes? You could store a the timeout time in the low priority queue
entry and keep a callout active for the head of the low priority queue. When
the callout runs, it moves the head item and any others with the same timeout up
to the normal queue and sets itself up to fire again for the next item on the
low priority queue. Then, if the normal queue is drained, low priority
requests can be handled with a minimum of latency. This could work by pulling
an item off the low priority queue to handle and resetting the callout for the
next one on the list. You could even handle that by basically calling the
funcion teh callout calls directly to move items up to the normal queue so you
can process them. As it is, by always blocking the full length of time, you
may be stalling a pending I/O while the disk is idle. Then if a higher
priority request comes in while we are handling the low priority request later
on after the nice process resumed, we may actually be increasing the latency of
that high priority request since it would not have had to wait had the low
priority request been handled during the idle time.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011214153151.jhb>