lkml.org 
[lkml]   [2006]   [Jul]   [5]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 05 Jul 2006 18:03:55 +1000
FromPeter Williams <>
SubjectRe: [PATCH] sched: Add SCHED_BGND (background) scheduling policy
Ingo Molnar wrote:
> * Peter Williams <pwil3058@bigpond.net.au> wrote:
> 
>> ===================================================================
>> --- MM-2.6.17-mm6.orig/kernel/mutex.c	2006-07-04 14:37:43.000000000 +1000
>> +++ MM-2.6.17-mm6/kernel/mutex.c	2006-07-04 14:38:12.000000000 +1000
>> @@ -51,6 +51,16 @@ __mutex_init(struct mutex *lock, const c
>> 
>>  EXPORT_SYMBOL(__mutex_init);
>> 
>> +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.

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?

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce
-
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/

\
 
 \ /
  Last update: 2006-07-05 08:07    [from the cache]
©2003-2008