* Peter Williams <[email protected]> wrote:
> >>+static inline void inc_mutex_count(void)
> >>+{
> >>+ current->mutexes_held++;
> >>+}
> >>+
> >>+static inline void dec_mutex_count(void)
> >>+{
> >>+ current->mutexes_held--;
> >>+}
> >>+
> >
> >NACK! This whole patch is way too intrusive for such a relatively small
> >gain.
> >
> >also, if something doesnt hold a mutex, it might still be unsafe to
> >background it! For example if it holds a semaphore. Or an rwsem. Or any
> >other kernel resource that has exclusion semantics.
> >
> >so unless this patch gets _much_ less complex and much less intrusive,
> >we'll have to stay with SCHED_BATCH and nice +19.
>
> This means being less strict but (as you imply) that may be not much
> better than nice +19. I'll have a look at it.
it's way too much pain for little gain.
> Of course, a comprehensive (as opposed to RT only) priority
> inheritance mechanism would make the "safe/unsafe to background"
> problem go away and make this patch very simple. Any plans in that
> direction?
that seems quite unlikely to happen. I think you are missing the biggest
issue: for RT, if the priority inheritance mechanism does not extend to
a given scheduling pattern it causes longer latencies, but no harm is
done otherwise. But for SCHED_BGND we'd have to make sure _every_ place
is priority-inversions safe - otherwise we risk a potential local DoS if
a task with a critical resource is backgrounded! That's plain impossible
to achieve.
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]
