Messages in this thread | | | Date | Mon, 14 Jan 2002 06:48:53 -0700 | From | yodaiken@fsmlabs ... | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
I forgot the line that says: "Oliver pointed out the immediate problem but .."
On Mon, Jan 14, 2002 at 06:45:48AM -0700, yodaiken@fsmlabs.com wrote: > On Mon, Jan 14, 2002 at 02:17:46PM +0200, Momchil Velikov wrote: > > >>>>> "yodaiken" == yodaiken <yodaiken@fsmlabs.com> writes: > > yodaiken> It's not even clear how preempt is supposed to interact with SCHED_FIFO. > > > > How so ? The POSIX specification is not clear enough or it is not to be followed ? > > POSIX makes no specification of how scheduling classes interact - unless something changed > in the new version. > > But more than that, the problem of preemption is much more complex when you have > task that do not share the "goodness fade" with everything else. That is, given a > set of SCHED_OTHER processes at time T0, it is reasonable to design the scheduler so > that there is some D so that by time T0+D each process has become the highest priority > and has received cpu up to either a complete time slice or a I/O block. Linux kind of > has this property now, and I believe that making this more robust and easier to analyze > is going to be an enormously important issue. However, once you add SCHED_FIFO in the > current scheme, this becomes more complex. And with preempt, you cannot even offer the > assurance that once a process gets the cpu it will make _any_ advance at all. > > > > -- > --------------------------------------------------------- > Victor Yodaiken > Finite State Machine Labs: The RTLinux Company. > www.fsmlabs.com www.rtlinux.com
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |