Remove tq_scheduler

This patch removes tq_scheduler from the kernel. All uses of tq_scheduler are migrated over to use schedule_task().

Notes:

- In two places: drivers/block/paride/pseudo.h and drivers/net/wan/sdlamain.c we are re-adding tasks to tq_scheduler within the callback. That means that these functions are being called _every_ time the machine calls schedule().

It may be a limited case for paride, but sdlamain.c appears to be doing this wicked thing all the time.

Now, if you do this with the current schedule_task() your machine will hang up. So schedule_task() has been changed to support this practice. If we see that the task queue has waiters on it we still call schedule(), but we do it in state TASK_RUNNING.

- The patch adds to context.c a new API function run_schedule_tasks() which immediately runs the queued tasks. Must only be called from process context. serial.c needs this in its shutdown routines.

- If anyone sleeps in a callback, then all other users of schedule_task() also sleep. But there's nothing new here. Kinda makes one wonder why schedule_task exists. But what-hey, it's neat.

- Note the careful massaging of module reference counts.

Yes my friends, much usage of task queues in modules is racy wrt module removal. This patch fixes some of them.

The approach taken here is to increment the module refcount when we enqueue a task and to decrement it in the handler:

	mainline()
	{
		...
		MOD_INC_USE_COUNT;
		if (schedule_task(some_wq) == 0)
			MOD_DEC_USE_COUNT;
	}

	handler()
	{
		...
		MOD_DEC_USE_COUNT;
		/* Wheee!  Tiny race here */
		return;
	}

Note that queue_task and schedule_task have been enhanced to return a success indicator. If this is non-zero you know that your task will be run. If it returns zero then your tq_struct was already queued and you lose.

The patch against test11-pre7 (1043 lines) is at

http://www.uow.edu.au/~andrewm/linux/tq_scheduler.patch

It affects the following files:

include/linux/tqueue.h
include/linux/sched.h
include/linux/compatmac.h
arch/ppc/8xx_io/uart.c
arch/ppc/8xx_io/fec.c
arch/ppc/8260_io/uart.c
drivers/net/wan/sdlamain.c
drivers/block/paride/pseudo.h
drivers/char/tty_io.c
drivers/char/esp.c
drivers/char/istallion.c
drivers/char/riscom8.c
drivers/char/serial.c
drivers/char/README.epca
drivers/char/specialix.c
drivers/char/epca.c
drivers/char/isicom.c
drivers/char/moxa.c
drivers/char/mxser.c
drivers/char/stallion.c
drivers/scsi/megaraid.c
drivers/scsi/qla1280.c
drivers/isdn/avmb1/b1capi.c
drivers/isdn/avmb1/kcapi.c
drivers/sbus/char/sab82532.c
drivers/sbus/char/aurora.c
drivers/ide/ide.c
drivers/usb/serial/keyspan_pda.c drivers/usb/serial/digi_acceleport.c
drivers/i2o/i2o_lan.c
fs/smbfs/sock.c
kernel/sched.c
kernel/ksyms.c
kernel/timer.c
kernel/context.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Because you're only supposed to use it if the task that is scheduled:
A) Doesn't care about a reasonable delay
B) Doesn't sleep for an unreasonable amount of time.

As long as there's some value of 'reasonable' to match the set of tasks which you are using schedule_task() for at any given moment, you should be fine.

If it's really necessary in 2.5, we can consider using multiple queues to get round this problem - either a task per subsystem or a pool of worker threads. Hopefully it won't be necessary though. We'll see.

Cool. I was going to look into that. I had figured we should fix it completely or not at all, though, which is why I didn't do the trick with use counts. I probably should have done, though.

While you're in maintenance mode, do you feel like fixing up stuff to use up_and_exit() for killing kernel threads? I started on net/sunrpc/sched.c but it made my head hurt so I gave up and started hacking PCMCIA instead :)

Also, drivers/usb/hub.c can probably use schedule_task() now instead of its own kernel thread.

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrew, can you put your patches on a properly configured site. The site admins have all ICMP packets blocked on www.uow.edu.au so you are a PMTU blackhole and unreachable via my tunnel.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Or configure your host to do MSS Clamping. I have a similar situation over here and no problems.

Regards,

bert hubert

PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/