Re: use of preempt_count instead of in_atomic() at leds-gpio.c

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Henrique de Moraes Holschuh
Date: Thursday, March 20, 2008 - 3:56 pm

On Tue, 18 Mar 2008, Andrew Morton wrote:

Well, it is obvious an "are we in a sleep-ok state?" query that works in any
case is desired by a lot of code.

I certainly don't want to punt every thinkpad LED write to a workqueue,
because that would mean less time with the CPU in C3 in the bottom line,
even if there are some benefits to always doing it the workqueue way (the
workqueue helper colapses attempts to change the LED state too often).

Can we add "in_scheduleable()", or maybe "can_schedule()", that returns
in_atomic() if CONFIG_PREEMT, or 0 if there is no way to know?   To my
limited knowledge of how that part of the kernel works, it would do the
right thing.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Sun Mar 16, 11:43 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 3:56 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 5:36 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 7:10 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Fri Mar 21, 5:37 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Wed Mar 26, 9:17 am)