Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 31 Mar 2005 23:59:27 -0800 | From | Andrew Morton <> | Subject | Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector. |
| |
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote: > > On Thu, 2005-03-31 at 23:26 -0800, Andrew Morton wrote: > > Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote: > > > > > > > > +static int cbus_event_thread(void *data) > > > > > +{ > > > > > + int i, non_empty = 0, empty = 0; > > > > > + struct cbus_event_container *c; > > > > > + > > > > > + daemonize(cbus_name); > > > > > + allow_signal(SIGTERM); > > > > > + set_user_nice(current, 19); > > > > > > > > Please use the kthread api for managing this thread. > > > > > > > > Is a new kernel thread needed? > > > > > > Logic behind cbus is following: > > > 1. make insert operation return as soon as possible, > > > 2. deferring actual message delivering to the safe time > > > > > > That thread does second point. > > > > But does it need a new thread rather than using the existing keventd? > > Yes, it is much cleaner [especially from performance tuning point] > to use own kernel thread than pospone all work to the queued work. >
Why? Unless keventd is off doing something else (rare), it should be exactly equivalent. And if keventd _is_ off doing something else then that will slow down this kernel thread too, of course.
Plus keventd is thread-per-cpu and quite possibly would be faster. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |