On Thu, 2005-03-31 at 23:59 -0800, Andrew Morton wrote: > Evgeniy Polyakov <[email protected]> wrote: > > > > On Thu, 2005-03-31 at 23:26 -0800, Andrew Morton wrote: > > > Evgeniy Polyakov <[email protected]> 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. keventd does very hard jobs on some of my test machines which for example route big amount of traffic. > Plus keventd is thread-per-cpu and quite possibly would be faster. I experimented with several usage cases for CBUS and it was proven to be the fastest case when only one sending thread exists which manages only very limited amount of messages at a time [like 10 in CBUS currently] without direct awakening [that is why wake_up() is commented in cbus_insert()]. If too many deferred insert works will be called simultaneously [which may happen with keventd] it will slow down insert operations noticeably. I did not try that case with the keventd but with one kernel thread it was tested and showed worse performance. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- References:
- Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- From: Andrew Morton <[email protected]>
- Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- From: Evgeniy Polyakov <[email protected]>
- Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- From: Andrew Morton <[email protected]>
- Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- From: Evgeniy Polyakov <[email protected]>
- Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- From: Andrew Morton <[email protected]>
- Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- Prev by Date: [PATCH] Kprobes: Incorrect handling of probes on ret/lret instruction
- Next by Date: Re: Linux virtual memory manager
- Previous by thread: Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- Next by thread: Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
- Index(es):