lkml.org 
[lkml]   [2008]   [Feb]   [25]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 25 Feb 2008 00:20:14 -0500
FromGregory Haskins <>
SubjectRe: [PATCH [RT] 11/14] optimize the !printk fastpath through the lock acquisition
Bill Huey (hui) wrote:
> 
> The might_sleep is annotation and well as a conditional preemption
> point for the regular kernel. You might want to do a schedule check
> there, but it's the wrong function if memory serves me correctly. It's
> reserved for things that actually are design to sleep.

Note that might_sleep() already does a cond_resched() on the 
configurations that need it, so I am not sure what you are getting at 
here.  Is that not enough?


> The rt_spin*()
> function are really a method of preserving BKL semantics across real
> schedule() calls. You'd have to use something else instead for that
> purpose like cond_reschedule() instead.

I dont quite understand this part either.  From my perspective, 
rt_spin*() functions are locking constructs that might sleep (or might 
spin with the new patches), and they happen to be BKL and wakeup 
transparent.  To me, either the might_sleep() is correct for all paths 
that don't fit the in_atomic-printk exception, or none of them are.

Are you saying that the modified logic that I introduced is broken?  Or 
that the original use of the might_sleep() annotation inside this 
function is broken?

-Greg


\
 
 \ /
  Last update: 2008-02-25 06:23    [from the cache]
©2003-2008