Re: [Xenomai] Suggested approach to schedule N-RT work in kernel on a specific CPU core

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Sun, Mar 20, 2016 at 08:20:36AM +0000, Alex Plits wrote:
> 
> 
> > -----Original Message-----
> > From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> > Sent: Sunday, March 20, 2016 10:00 AM
> > To: Alex Plits
> > Cc: xenomai@xenomai.org
> > Subject: Re: [Xenomai] Suggested approach to schedule N-RT work in kernel
> > on a specific CPU core
> > 
> > On Sun, Mar 20, 2016 at 07:49:16AM +0000, Alex Plits wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> > > > If the Linux kernel provides a function to do this, we could
> > > > implement a function mirroring that function in the RTDM API. Looks
> > > > simple. Am I missing something ?
> > > >
> > >
> > > [Alex Plits] The Linux provides an option to configure the workQ on
> > > specific CPU's on it's initialization stage of the WorkQ. I'm unsure
> > > Of how/whether it actually schedules it's execution when schedule_work
> > > is called from a different CPU core that it was configured up-on.
> > 
> > I doubt very much this does not work. Have you tried it and observed that it
> > does not work?
> > 
> > 
> > 
> > > I'm guessing that if it were trivial the same mechanism would also be
> > > used in the current API for N-RT or xenomai printk mechanism (both use
> > > dedicated workQs which are different than Linux WorkQs awaken via
> > > VIRQs).
> > 
> > There is no xenomai printk mechanism. printk is implemented by the I-pipe
> > patch, a layer below Xenomai, so can not use an RTDM service.
> > Besides, the I-pipe patch printk implementation predates
> > ipipe_post_work_root.
> > 
> > The way RTDM work works is with the ipipe_post_work_root service, so it
> > does not use virqs, and since the schedule_work gets invoked in a plain linux
> > context, anything which works with schedule_work (like triggering a work
> > queue on a different cpu) should work with the RTDM service.
> > 
> > So, again, have you tried running the RTDM service with a work queue
> > pinned on a different cpu and observed that it did not work?
> > 
> [Alex Plits] 
> First off, thanks for such quick replies!
> Secondly no I have not tried since I have not seen such an example.
> So basically what you're saying - 
> Run schedule_work in handler which is scheduled by rtdm_schedule_nrt_work and use some linux defined workQ with cpu "affinity" - right?

I meant simply use rtdm_schedule_nrt_work with a work queue that has
been pinned on a given cpu. rtdm_schedule_nrt_work simply gets
schedule_work invoked in a plain linux context. So, there should not
be much difference between using rtdm_schedule_nrt_work and
schedule_work. The only difference being that rtdm_schedule_nrt_work
can be invoked in head domain.

-- 
					    Gilles.
https://click-hack.org