From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 20 Mar 2016 09:38:09 +0100 From: Gilles Chanteperdrix Message-ID: <20160320083809.GH3345@hermes.click-hack.org> References: <20160320072520.GF3345@hermes.click-hack.org> <20160320075938.GG3345@hermes.click-hack.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Xenomai] Suggested approach to schedule N-RT work in kernel on a specific CPU core List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Plits Cc: "xenomai@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