On 07/21/2015 03:42 PM, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 12:34 PM, Chris Metcalf wrote:
Second, you suggest a tracepoint. I'm OK with creating a tracepoint
dedicated to cpu_isolated strict failures and making that the only
way this mechanism works. But, earlier community feedbac
On Tue, Jul 21, 2015 at 12:34 PM, Chris Metcalf wrote:
> On 07/13/2015 05:47 PM, Andy Lutomirski wrote:
>>
>> On Mon, Jul 13, 2015 at 12:57 PM, Chris Metcalf
>> wrote:
>>>
>>> With cpu_isolated mode, the task is in principle guaranteed not to be
>>> interrupted by the kernel, but only if it behav
On 07/13/2015 05:47 PM, Andy Lutomirski wrote:
On Mon, Jul 13, 2015 at 12:57 PM, Chris Metcalf wrote:
With cpu_isolated mode, the task is in principle guaranteed not to be
interrupted by the kernel, but only if it behaves. In particular, if it
enters the kernel via system call, page fault, or
On Mon, Jul 13, 2015 at 12:57 PM, Chris Metcalf wrote:
> With cpu_isolated mode, the task is in principle guaranteed not to be
> interrupted by the kernel, but only if it behaves. In particular, if it
> enters the kernel via system call, page fault, or any of a number of other
> synchronous traps
With cpu_isolated mode, the task is in principle guaranteed not to be
interrupted by the kernel, but only if it behaves. In particular, if it
enters the kernel via system call, page fault, or any of a number of other
synchronous traps, it may be unexpectedly exposed to long latencies.
Add a simple
5 matches
Mail list logo
