what would be the way of starting a sub-process in a module which then would
run in the background? I guess plain fork() won't work?
x = kernel_thread(&func, &arg, flags);
might do what you want.
~Randy_________________________________________
|randy.dunlap_at_intel.com 503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
-----------------------------------------------
> From: Heusden, Folkert van [mailto:[email protected]]
>
> what would be the way of starting a sub-process in a module
> which then would
> run in the background? I guess plain fork() won't work?
> -
You write:
> what would be the way of starting a sub-process in a module which then would
> run in the background? I guess plain fork() won't work?
We did this in one of our filesystem modules to have our own async cache
flush daemon. One thing you need to watch out for is that the new thread
is stopped before the module is unloaded. You can't simply increase the
module reference count, and decrease it when the thread exits, because
you are never allowed to remove a module with a non-zero refcount.
What you need to do is have your module cleanup function stop the thread,
and then wait to be sure it has exited before unloading. This is a
bit more tricky because you could send the thread a KILL signal and it is
still doing work or is rescheduled before it has completed exiting.
Check out obdfs/flushd.c (pupdated, obdfs_flushd_init, obdfs_flushd_cleanup)
and obdfs/super.c (init_module, init_obdfs, cleanup_module) at:
ftp://ftp.stelias.com/pub/obd/obd-0.004.tgz
This module also does slab-cache initialization and cleanup (properly!),
so that is also worth looking at.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Andreas Dilger wrote:
>
> You write:
> > what would be the way of starting a sub-process in a module which then would
> > run in the background? I guess plain fork() won't work?
>
> We did this in one of our filesystem modules to have our own async cache
> flush daemon. One thing you need to watch out for is that the new thread
> is stopped before the module is unloaded. You can't simply increase the
> module reference count, and decrease it when the thread exits, because
> you are never allowed to remove a module with a non-zero refcount.
>
> What you need to do is have your module cleanup function stop the thread,
> and then wait to be sure it has exited before unloading. This is a
> bit more tricky because you could send the thread a KILL signal and it is
> still doing work or is rescheduled before it has completed exiting.
I do this too, in Tux2. The idea seems to have occured independently to
every filesystem group, or perhaps necessity is a better term for it.
So, having observed that every filesystem already has such a background
thread associated with it (all the dumb filesystems are associated with
kflush+kupdate) why don't we think about how we can do this in a more
organized way?
Here's something that looks like a piece of the puzzle:
http://boudicca.tux.org/hypermail/linux-kernel/2000week45/0266.html
RE: Linux's implementation of poll() not scalable?
I'd like to have my filesystem thread get woken up on messages from the
VM, specifically to handle flush requests of the kind that are needed to
clean buffers so the VM can evict some pages. There are other messages
I'd like to see to, for example: 'please clean up and unmount this
superblock'. I need to wake periodically too, and a timer sleep is one
way to do that, but another is to receive a message from a timer - that
way I don't have to figure out why I've been woken up. And I'd like to
receive messages from other threads that visit my own filesystem, for
example: 'transaction done, ok to change phases' - so the message queue
would have multiple writers, one reader. In all these cases, the
superblock would be passed as part of the message so one thread would be
able to service multiple mounts.
Does any of this make sense?
--
Daniel