* Re: Fix up riscom8 driver to use work queues instead of task queueing. [not found] <200308181806.h7II6K6D014918@hera.kernel.org> @ 2003-08-18 18:09 ` Jeff Garzik 2003-08-18 18:21 ` Linus Torvalds 0 siblings, 1 reply; 12+ messages in thread From: Jeff Garzik @ 2003-08-18 18:09 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: torvalds On Mon, Aug 18, 2003 at 04:59:53PM +0000, Linux Kernel Mailing List wrote: > @@ -425,7 +414,7 @@ > > *tty->flip.char_buf_ptr++ = ch; > tty->flip.count++; > - queue_task(&tty->flip.tqueue, &tq_timer); > + schedule_delayed_work(&tty->flip.work, 1); > } > > static inline void rc_receive(struct riscom_board const * bp) > @@ -456,7 +445,7 @@ > *tty->flip.flag_buf_ptr++ = 0; > tty->flip.count++; > } > - queue_task(&tty->flip.tqueue, &tq_timer); > + schedule_delayed_work(&tty->flip.work, 1); > } > > static inline void rc_transmit(struct riscom_board const * bp) Should we just make schedule_delayed_work(foo, 1) the default for a schedule_work() call? I'm seeing this construct pop up more and more... and would rather have it fixed at the source, not in every driver. Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 18:09 ` Fix up riscom8 driver to use work queues instead of task queueing Jeff Garzik @ 2003-08-18 18:21 ` Linus Torvalds 2003-08-18 18:28 ` Russell King 2003-08-18 18:44 ` Jeff Garzik 0 siblings, 2 replies; 12+ messages in thread From: Linus Torvalds @ 2003-08-18 18:21 UTC (permalink / raw) To: Jeff Garzik; +Cc: Linux Kernel Mailing List On Mon, 18 Aug 2003, Jeff Garzik wrote: > > Should we just make schedule_delayed_work(foo, 1) the default for a > schedule_work() call? Why? There are cases where you may really want to get the work done asap, so the regular "schedule_work()" is the right thing. While the "delayed" thing is for stuff that explicitly doesn't want to happen immediately, because we expect to aggregate more into it. Having done a few serial drivers (not because I want to, but because nobody else seems to be doing them), I definitely see the need for both. For example, the hangup case wants to be done asap, not delayed. Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 18:21 ` Linus Torvalds @ 2003-08-18 18:28 ` Russell King 2003-08-18 18:47 ` Linus Torvalds 2003-08-18 18:44 ` Jeff Garzik 1 sibling, 1 reply; 12+ messages in thread From: Russell King @ 2003-08-18 18:28 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jeff Garzik, Linux Kernel Mailing List On Mon, Aug 18, 2003 at 11:21:07AM -0700, Linus Torvalds wrote: > Having done a few serial drivers (not because I want to, but because > nobody else seems to be doing them), I definitely see the need for both. Of course, the more correct approach is for someone to convert them to use the new serial driver core (and fix the driver core interface to allow them to work with it.) Unfortunately I don't have the hardware for a lot of these specialist serial cards, so it's a job I've steared clear of. I've been hoping that leaving them broken will make the ones which are used stand out, and hopefully someone with the hardware would've picked them up and done the necessary conversion. But alas no. (I did my best to convert dz.c without the hardware, but it seems to have been lost into the depths of the MIPS tree... *hint*) -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 18:28 ` Russell King @ 2003-08-18 18:47 ` Linus Torvalds 2003-08-18 18:59 ` Russell King 0 siblings, 1 reply; 12+ messages in thread From: Linus Torvalds @ 2003-08-18 18:47 UTC (permalink / raw) To: Russell King; +Cc: Jeff Garzik, Linux Kernel Mailing List On Mon, 18 Aug 2003, Russell King wrote: > > Of course, the more correct approach is for someone to convert them to > use the new serial driver core (and fix the driver core interface to > allow them to work with it.) Hey, I'm all for that for 2.7.x. In the meantime, they've been broken for a year, so let's just try to fix them up into a "limping along" state. I don't have the hardware either, but at least now they should be testable on UP configurations (SMP is generally still broken due to the drivers expecting to be able to disable all interrups globally instead of using proper locking). I'd be interested to hear whether the dang things work. Of course, there probably aren't that many people around with the hardware any more. I could just have added them to the BROKEN list, but since they _might_ work it seemed like a better idea to be hugely optimistic instead ;) Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 18:47 ` Linus Torvalds @ 2003-08-18 18:59 ` Russell King 2003-08-18 19:10 ` Linus Torvalds 0 siblings, 1 reply; 12+ messages in thread From: Russell King @ 2003-08-18 18:59 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jeff Garzik, Linux Kernel Mailing List On Mon, Aug 18, 2003 at 11:47:14AM -0700, Linus Torvalds wrote: > I'd be interested to hear whether the dang things work. Of course, there > probably aren't that many people around with the hardware any more. I > could just have added them to the BROKEN list, but since they _might_ work > it seemed like a better idea to be hugely optimistic instead ;) True. However, there is the opposite point of view which is equally valid. There aren't many people with the hardware, and the people that there are aren't interested in development kernel series, so even if we did convert them during 2.7, we wouldn't hear about it until 2.8. IMO its far better to do these types of conversions when users are interested in the driver (and can therefore give you bug reports) than when they are actively ignoring the development series. Both positions are equally valid. I'm not going to argue that one is more valid than the other because I have enough on my plate for the time being. 8) -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 18:59 ` Russell King @ 2003-08-18 19:10 ` Linus Torvalds 0 siblings, 0 replies; 12+ messages in thread From: Linus Torvalds @ 2003-08-18 19:10 UTC (permalink / raw) To: Russell King; +Cc: Jeff Garzik, Linux Kernel Mailing List On Mon, 18 Aug 2003, Russell King wrote: > > True. However, there is the opposite point of view which is equally > valid. There aren't many people with the hardware, and the people > that there are aren't interested in development kernel series, so > even if we did convert them during 2.7, we wouldn't hear about it > until 2.8. Yes. However, what worries me more is that there are people who have the hardware, but because the driver won't even compile for them, they just go "oh, well, I'll try it again when the _real_ 2.6.0 hits the streets". Which obviously won't work. So I'm trying to make sure that all the broken drivers are gotten to a working state. Right now, considering how long they've been broken, that means "it must compile" so that people can test them. The "leave it broken, so that somebody will fix it properly some day" approach is a fine one for early development series. But right now I'd prefer to see patches to make drivers compile cleanly, even if people can't test them on real hardware. The intersection of people who have the hardware, and people who have the time/knowledge to convert a driver, may be empty. Expecially for odd hardware. So let's get those drivers compiling, even if we can't test them, so that others _can_ test them. Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 18:21 ` Linus Torvalds 2003-08-18 18:28 ` Russell King @ 2003-08-18 18:44 ` Jeff Garzik 2003-08-18 19:12 ` Linus Torvalds 1 sibling, 1 reply; 12+ messages in thread From: Jeff Garzik @ 2003-08-18 18:44 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List On Mon, Aug 18, 2003 at 11:21:07AM -0700, Linus Torvalds wrote: > > On Mon, 18 Aug 2003, Jeff Garzik wrote: > > > > Should we just make schedule_delayed_work(foo, 1) the default for a > > schedule_work() call? > > Why? There are cases where you may really want to get the work done asap, > so the regular "schedule_work()" is the right thing. While the "delayed" schedule_work() is _not_ for that. As currently implemented, you have no guarantees that your schedule_work()-initiated work will even begin in this century. Drivers are using schedule_work() to create process contexts where they can sleep, potentially for many seconds. On a single cpu system, or a loaded SMP system, schedule_work() from one of the drivers you converted could easily be delayed for 30 seconds or more. schedule_work() is not a fast path. If work needs to happen ASAP, then you really want to replace those schedule_work() calls with schedule_tasklet() calls that do the "must be done asap" work, and then schedule_work() the stuff that requires process context... So, too, I would have thought that bottom-half completion routines mapped more directly to schedule_tasklet() anyway. Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 18:44 ` Jeff Garzik @ 2003-08-18 19:12 ` Linus Torvalds 2003-08-18 19:25 ` Jeff Garzik 0 siblings, 1 reply; 12+ messages in thread From: Linus Torvalds @ 2003-08-18 19:12 UTC (permalink / raw) To: Jeff Garzik; +Cc: Linux Kernel Mailing List On Mon, 18 Aug 2003, Jeff Garzik wrote: > > schedule_work() is _not_ for that. As currently implemented, you have > no guarantees that your schedule_work()-initiated work will even > begin in this century. In theory yes. In practice no. schedule_work() tries to wake up the worker process immediately, and as such usually gets the work done asap. But hey, if you want to improve on the drivers, please go wild. I care more about "real life working" than "theoretical but doesn't work". Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 19:12 ` Linus Torvalds @ 2003-08-18 19:25 ` Jeff Garzik 2003-08-18 19:36 ` Linus Torvalds 0 siblings, 1 reply; 12+ messages in thread From: Jeff Garzik @ 2003-08-18 19:25 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List On Mon, Aug 18, 2003 at 12:12:19PM -0700, Linus Torvalds wrote: > > On Mon, 18 Aug 2003, Jeff Garzik wrote: > > > > schedule_work() is _not_ for that. As currently implemented, you have > > no guarantees that your schedule_work()-initiated work will even > > begin in this century. > > In theory yes. In practice no. schedule_work() tries to wake up the worker > process immediately, and as such usually gets the work done asap. > > But hey, if you want to improve on the drivers, please go wild. I care > more about "real life working" than "theoretical but doesn't work". hehe ;-) well, * I've hit this situation in real life (waiting on a driver doing error handling, hogging the single shared workqueue on UP). It actually gets nasty if a bunch of drivers all throw errors at the same time... (more below) * re "improve the drivers" -- if you mean "fixing" those hogging the shared workqueue, I think that's a workqueue API flaw. If you mean further fix up the drivers you just modified, well... I think slackness on my part will win there :) There was talk in another thread about fixing up workqueue to create a new kernel thread, if one isn't available within five seconds. That seemed reasonable to me. Another useful addition to workqueue, for drivers, would be a one-shot thread "runme(func, func_data)" API. I think a lot of the device driver error handling is more appropriate to this one-shot API than the current workqueue API. Error handling is already a slow path, so the overhead of thread creation on each call is mitigated. Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 19:25 ` Jeff Garzik @ 2003-08-18 19:36 ` Linus Torvalds 2003-08-18 20:32 ` Andrew Morton 0 siblings, 1 reply; 12+ messages in thread From: Linus Torvalds @ 2003-08-18 19:36 UTC (permalink / raw) To: Jeff Garzik; +Cc: Linux Kernel Mailing List On Mon, 18 Aug 2003, Jeff Garzik wrote: > > There was talk in another thread about fixing up workqueue to create > a new kernel thread, if one isn't available within five seconds. That's probably reasonable. Together with some upper limit to active threads, along with timeouting old queues when idle it would be fairly flexible. It's how basically all servers end up working, after all. It shouldn't be that hard to do. Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 19:36 ` Linus Torvalds @ 2003-08-18 20:32 ` Andrew Morton 2003-08-18 21:24 ` Jeff Garzik 0 siblings, 1 reply; 12+ messages in thread From: Andrew Morton @ 2003-08-18 20:32 UTC (permalink / raw) To: Linus Torvalds; +Cc: jgarzik, linux-kernel Linus Torvalds <torvalds@osdl.org> wrote: > > > On Mon, 18 Aug 2003, Jeff Garzik wrote: > > > > There was talk in another thread about fixing up workqueue to create > > a new kernel thread, if one isn't available within five seconds. > > That's probably reasonable. Together with some upper limit to active > threads, along with timeouting old queues when idle it would be fairly > flexible. It's how basically all servers end up working, after all. It > shouldn't be that hard to do. > Note that pdflush is already doing this. It doesn't seem to work very well though: a) new threads seem to start up too late b) they probably don't hang around for long enough c) now that pdflush avoids blocking on queues it's all rather overkill anyway. pdflush could kinda-sorta be converted to use workqueues, but it doesn't want a thread per cpu. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fix up riscom8 driver to use work queues instead of task queueing. 2003-08-18 20:32 ` Andrew Morton @ 2003-08-18 21:24 ` Jeff Garzik 0 siblings, 0 replies; 12+ messages in thread From: Jeff Garzik @ 2003-08-18 21:24 UTC (permalink / raw) To: Andrew Morton; +Cc: Linus Torvalds, linux-kernel Andrew Morton wrote: > pdflush could kinda-sorta be converted to use workqueues, but it doesn't > want a thread per cpu. That was another item in the recent thread about workqueues: other kernel code is very suited to the workqueue API, but only needs one thread, not a thread per cpu. Would be nice to have a JUST_ONE_THREAD flag to pass to create_workqueue(). I bet adding such a flag would help alleviate some of the "I have 1001 kthreads on my 16-way" complaints ;-) Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-08-18 21:24 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200308181806.h7II6K6D014918@hera.kernel.org> 2003-08-18 18:09 ` Fix up riscom8 driver to use work queues instead of task queueing Jeff Garzik 2003-08-18 18:21 ` Linus Torvalds 2003-08-18 18:28 ` Russell King 2003-08-18 18:47 ` Linus Torvalds 2003-08-18 18:59 ` Russell King 2003-08-18 19:10 ` Linus Torvalds 2003-08-18 18:44 ` Jeff Garzik 2003-08-18 19:12 ` Linus Torvalds 2003-08-18 19:25 ` Jeff Garzik 2003-08-18 19:36 ` Linus Torvalds 2003-08-18 20:32 ` Andrew Morton 2003-08-18 21:24 ` Jeff Garzik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).