Date: Fri, 22 Feb 2002 07:59:52 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Jeff Roberson <jroberson@chesapeake.net>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG Subject: Re: Prioritized bio patches. (Updated patch) Message-ID: <3C766AF8.35B9E6B@mindspring.com> References: <20020219194142.M12686-100000@mail.chesapeake.net> <200202220106.g1M168p12213@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > I was thinking potentially of some sort of priority stealing > mechanism similar to the mechanism that exists for mutexes. > It would not be easy to implement though. We would have to > deal with vnode locks as well as buffer locks. I don't think this can work. There are serious inheritance tracking problems, when it comes to dealing with giving up an inherited priority on a directory entry block, a cylinder group block, or a frag, shared by two processes of different priority. This might be easier without soft updates, or with UFS2, when it happens. > Priority inversion can be a serious problem, especially in more > heavily loaded systems. I don't think it would be safe to commit > a bio priority mechanism without dealing with the problem. I think depending the priority tree from the slowest hardware interface is probably a bad idea, anyway. Really, people who are concerned about this problem will probably need to simply predo their conflicting operations on the directory hierarchy, and then make sure to allocate files in fs_blksiz sized chunks. If you can think of a clean way to inherit the proper priority, and switch back (the only thing I can think of is a lent priority stack per BIO, and that can't be a good idea), then I'd be happy to be proven wrong, since I'd get to learn something from it. 8-). > Another possibility is to guarentee that the I/O request will > eventually go out by slowly bumping up its priority in the queue, > so it doesn't get stuck indefinintely. Soft updates kinda/sorta tries to do this already by selection of the clock slot for insertion. I think that this can't work to "push back" operations of a lower priority, though (maybe it could -- by changing the head of the clock, and then inserting elements, but you'd be limited to 1/2 the clock size worth of inversion handlings before you were screwed). I think if something is *truly* high priority, then it is probably right to starve other processes; an application with near RT-requirements (e.g. video capture) may in fact *need* to hog 90% of system resources, and any "fairness" you inject into the mix to speed up other apps will cause it to break. Ah. I have an idea. Why don't you have a circular list of queued work, and then pick which slot relative to the head based on a deadline? If you can complete all the other I/O before hitting the deadline, fine, but if not, then you would complete it in deadline order. The system is overloaded when you can't meet the deadlines (e.g. there is more work on a queue than can be services in a clock tick), but at that point, you are overloaded, and the best you can do is a "best effort" approach anyway. Yes, this still leaves the possibility of starvation of lower priority processes. Actually, thinking of it this way, this out to be bound up in th RT prio stuff -- processes not running at RT prio should not enter into deadline contention at all: they should use the historical approach. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C766AF8.35B9E6B>