linux-kernel - Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Jul 2007 11:25:21 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Gregory Haskins <ghaskins@...ell.com>
Cc:	linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] RT: Preemptible Function-Call-IPI Support


* Ingo Molnar <mingo@...e.hu> wrote:

> * Gregory Haskins <ghaskins@...ell.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.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/