Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

On Thu, 2005-03-31 at 23:59 -0800, Andrew Morton wrote:
> 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.

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]