Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Steven Rostedt <[email protected]> wrote:

> I also see this with non rt tasks causing a burst of schedules.
> 
> 1. Process A runs and grabs lock L. then finishes its time slice.
> 2. Process B runs and tries to grab Lock L.
> 3. Process A runs and releases lock L.
> 4. __up_mutex gives process B lock L.
> 5. Process A tries to grab lock L.
> 6. Process B runs and releases lock L.
> 7. __up_mutex gives lock L to process A.
> 8. Process B tries to grab lock L again.
> 9. Process A runs...
> 
> Here we have more unnecessary schedules.  So the condition to grab a lock
> should be:
> 
> 1. not owned.
> 2. partially owned, and the owner is not RT.
> 3. partially owned but the owner is RT and so is the grabber, and the
>     grabber's priority is >= the owner's priority.

yeah, sounds good - but i'd not make any distinction between RT and 
non-RT tasks - just make the rule #3 distinction based on ->prio. In 
particular on UP a task should only run when its higher prio, so if a 
lock is 'partially owned' then the priority rule should always be true.  
(On SMP it's a bit more complex, there the priority rule could make a 
real difference.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux