All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] VFCIPI support v2
@ 2007-07-30 21:15 Gregory Haskins
  2007-07-30 21:15 ` [PATCH 1/2] RT: Preemptible Function-Call-IPI Support Gregory Haskins
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Gregory Haskins @ 2007-07-30 21:15 UTC (permalink / raw)
  To: linux-rt-users; +Cc: ghaskins

The following series Virtual Function-Call IPI support.  Changes from v1:

1) Support for platforms other than x86_64
2) Support for priority-inheritance.

Built/tested on x86_64 four-way SMP machine.  Other platforms untested.

Signed-off-by: Gregory Haskins <ghaskins@novell.com>

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support
@ 2007-07-31 11:44 Gregory Haskins
  0 siblings, 0 replies; 14+ messages in thread
From: Gregory Haskins @ 2007-07-31 11:44 UTC (permalink / raw)
  To: mingo; +Cc: linux-kernel, linux-rt-users

On Tue, 2007-07-31 at 11:21 +0200, Ingo Molnar wrote:
> [ mail re-sent with lkml Cc:-ed. _Please_ Cc: all patches to lkml too! 
>   Unless you want -rt to suffer the fate of -ck, keep upstream involved 
>   all the time. The recent /proc/interrupts-all discussion with upstream 
>   folks showed the clear benefits of that approach. ]

My apologies.  I wasn't getting really any responses to my proposal, so
I shortened the distribution to avoid becoming a pest to people that
didn't care.  I will CC both from now on.


> 
> why do we need this? 

I wrote this when I discovered that KVM was having problems with
smp_call_function() on -rt.  It was utilizing spinlock_t which of course
was transparently converted to rt_mutex.  This blew up in the interrupt
context of the FUNCTION_CALL whenever the lock was acquired.  I was
thinking to myself "why is the FCIPI vector being treated any different
that other IRQs?".  That question drove the design/implementation of
this series.


> It's quite complex 


I think if you look closely at the code you will see its actually pretty
straight forward.  However, for whatever complexity you may perceive,
note that I made the choices I did (as opposed to something like
modifying the work-queue infrastructure) because I felt it had the
minimum impact on other subsystems unrelated to FCIPI.  There are, of
course, many ways to skin a rabbit. ;)

> and brings little extra AFAICS.

Brings little extra to what?  Do you think the whole concept of "FCIPIs
in a thread" is a waste of time, or do you just think my implementation
choices are bad?

> See the "schedule_on_each_cpu-enhance.patch" from Peter Ziljstra that 
> lets a function to be executed on all CPUs. That should be extended 
> (trivially) to execute a function on another CPU. That's all we need.

I haven't seen that.  I will take a look.  

The key part of my design is as follows:

1) No new API: smp_call_function_[single]) must just transparently
switch over to threaded mode (Just like the IRQ handler in
PREEMPT_HARDIRQs does)
2) Support priority inheritance:  Unlike normal HARDIRQs which can use a
relatively static priority assignment, FCIPIs are driven by another
software entity which may or may not have RT priority.  Therefore, being
able to execute the call in the same priority as the caller is critical,
IMO.  Calls are sorted and scheduled by priority.
3) More robust parallelism:  mainline smp_call_function has a system
wide serialization point when a call is made.  We should be able to
support a high degree of parallel access to prevent priority inversion.
This means more than one call can be in-flight at a time.  
4) Preemptible/sleepable code on both the caller and callee sides.
Today, both the caller and callee sides of the link are critical
sections with preemption disabled.
5) The API must work from both in_atomic()==1 and in_atomic()==0 modes.
In addition, it will opportunistically sleep while waiting for replies
if in_atomic()==0.

If we can make Peter's patch work within this criteria and people like
it better than what I put forth, that is fine by me.

Regards,
-Greg

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support
@ 2007-07-31 12:11 Gregory Haskins
  2007-07-31 14:22 ` Ingo Molnar
  0 siblings, 1 reply; 14+ messages in thread
From: Gregory Haskins @ 2007-07-31 12:11 UTC (permalink / raw)
  To: mingo; +Cc: linux-kernel, linux-rt-users

On Tue, 2007-07-31 at 11:25 +0200, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > * Gregory Haskins <ghaskins@novell.com> wrote:
> >  
> > > This code allows FUNCTION_CALL IPIs to become preemptible by 
> > > executing them in kthread context instead of interrupt context.  
> > > They are referred to as "Virtual Function Call IPIs" (VFCIPI) 
> > > because we no longer rely on the actual FCIPI facility.  Instead we 
> > > schedule a thread to run.  This essentially replaces the synchronous 
> > > FCIPI with an async RESCHEDULE IPI.
> > 
> > why do we need this? It's quite complex and brings little extra 
> > AFAICS. See the "schedule_on_each_cpu-enhance.patch" from Peter 
> > Ziljstra that lets a function to be executed on all CPUs. That should 
> > be extended (trivially) to execute a function on another CPU. That's 
> > all we need.
> 
> as far as the prioritization of function calls goes, _that_ makes sense, 
> but it should not be a separate API but should be done to our normal 
> workqueue APIs. That not only extends the effects of priorities to all 
> current workqueue using kernel subsystems, but also keeps the API more 
> unified. We really dont want to have too many -rt specific APIs.

I agree with you that having some kind of priority and cpu-binding
specifiers for work-queues would be very cool indeed.  However, note
that I didn't actually introduce a new API(*), per se.  I simply worked
under the existing smp_call_function[_single]() API.

Using the smp_call_functions is critical design factor, however.  I
really want clients of this function to seamlessly transition to
threaded mode.  So even if we ultimately can modify work-queues to have
those features mentioned, IMO we still need to modify the underlying
smp_call_function API to use the new workqueue stuff.  And more
importantly, the new workqueue APIs will have to be as flexible as the
current implementation to work in various modes (e.g. in_atomic=1 or 0,
etc).

(*)Ok, ok...i admit...There is one new API:  That is the legacy access
to the real FCIPI calls (which BTW, ive changed from
"smp_call_function__nodelay" to "raw_smp_call_function" in my latest
(and unreleased) series.  This makes them more in sync with some of the
other naming conventions in -rt).  So technically you are right ;) but
that is more of an implementation detail.  There are no users of the new
API other than the VFCIPI code.

Regards,
-Greg  

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [PATCH 0/2][RFC] VFCIPI v3
@ 2007-07-31 13:24 Gregory Haskins
  2007-07-31 13:24 ` [PATCH 1/2] RT: Preemptible Function-Call-IPI Support Gregory Haskins
  0 siblings, 1 reply; 14+ messages in thread
From: Gregory Haskins @ 2007-07-31 13:24 UTC (permalink / raw)
  To: linux-rt-users; +Cc: linux-kernel, ghaskins

Changelog from v2:

1) Converted "smp_call_funtion[_single]__nodelay" to
   "raw_smp_call_function[_single]" to match existing nomenclature in the -rt
   series.

2) Removed all PI related code from Patch #1 and moved it to #2 where it
   belonged.

Signed-off-by: Gregory Haskins <ghaskins@novell.com> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2007-07-31 20:36 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-30 21:15 [PATCH 0/2] VFCIPI support v2 Gregory Haskins
2007-07-30 21:15 ` [PATCH 1/2] RT: Preemptible Function-Call-IPI Support Gregory Haskins
2007-07-31  9:19   ` Ingo Molnar
2007-07-31  9:21     ` Ingo Molnar
2007-07-31  9:25       ` Ingo Molnar
2007-07-31 14:26         ` Gregory Haskins
2007-07-31 14:26         ` Gregory Haskins
2007-07-31 20:14           ` Gregory Haskins
2007-07-30 21:15 ` [PATCH 2/2] RT: Add priority inheritance to the VFCIPI facility Gregory Haskins
2007-07-30 21:34 ` [PATCH 0/2] VFCIPI support v2 Daniel Walker
  -- strict thread matches above, loose matches on Subject: below --
2007-07-31 11:44 [PATCH 1/2] RT: Preemptible Function-Call-IPI Support Gregory Haskins
2007-07-31 12:11 Gregory Haskins
2007-07-31 14:22 ` Ingo Molnar
2007-07-31 13:24 [PATCH 0/2][RFC] VFCIPI v3 Gregory Haskins
2007-07-31 13:24 ` [PATCH 1/2] RT: Preemptible Function-Call-IPI Support Gregory Haskins

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.