On May 3, 2014 3:19 PM, "H. Peter Anvin" wrote:
>
> On 05/03/2014 04:24 AM, Steven Rostedt wrote:
> > On Fri, 02 May 2014 21:03:10 -0700
> > "H. Peter Anvin" wrote:
> >
> >>
> >> I'd really like to see a workload which would genuinely benefit before
> >> adding more complexity. Now... if we can
On May 3, 2014 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see a workload which would genuinely benefit before
adding more complexity. Now... if
We have to do that anyway to deal with 16- and 32-bit userspace return.
On May 3, 2014 5:31:41 PM PDT, Andy Lutomirski wrote:
>On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski
>wrote:
>> On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin wrote:
>>> On 05/03/2014 04:24 AM, Steven Rostedt wrote:
Not for return from NMIs themselves, to be sure
On May 3, 2014 4:51:37 PM PDT, Andy Lutomirski wrote:
>On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin wrote:
>> On 05/03/2014 04:24 AM, Steven Rostedt wrote:
>>> On Fri, 02 May 2014 21:03:10 -0700
>>> "H. Peter Anvin" wrote:
>>>
I'd
On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski wrote:
> On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin wrote:
>> On 05/03/2014 04:24 AM, Steven Rostedt wrote:
>>> On Fri, 02 May 2014 21:03:10 -0700
>>> "H. Peter Anvin" wrote:
>>>
I'd really like to see a workload which would
On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin wrote:
> On 05/03/2014 04:24 AM, Steven Rostedt wrote:
>> On Fri, 02 May 2014 21:03:10 -0700
>> "H. Peter Anvin" wrote:
>>
>>>
>>> I'd really like to see a workload which would genuinely benefit before
>>> adding more complexity. Now... if we can
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
> On Fri, 02 May 2014 21:03:10 -0700
> "H. Peter Anvin" wrote:
>
>>
>> I'd really like to see a workload which would genuinely benefit before
>> adding more complexity. Now... if we can determine that it doesn't harm
>> anything and would solve the
On 05/03/2014 06:54 AM, Linus Torvalds wrote:
> On Fri, May 2, 2014 at 11:12 PM, H. Peter Anvin wrote:
>> On 05/02/2014 09:32 PM, Linus Torvalds wrote:
>>>
>>> At least as a proof-of-concept, having a code sequence in user mode
>>> trampoline that does
>>>
>>>popq %rsi
>>>popq %r11
>>>
On Fri, May 2, 2014 at 11:12 PM, H. Peter Anvin wrote:
> On 05/02/2014 09:32 PM, Linus Torvalds wrote:
>>
>> At least as a proof-of-concept, having a code sequence in user mode
>> trampoline that does
>>
>>popq %rsi
>>popq %r11
>>retq $128
>>
>> and building up a stack in user space
On Fri, 02 May 2014 21:03:10 -0700
"H. Peter Anvin" wrote:
>
> I'd really like to see a workload which would genuinely benefit before
> adding more complexity. Now... if we can determine that it doesn't harm
> anything and would solve the NMI nesting problem cleaner than the
> current
On 05/02/2014 09:32 PM, Linus Torvalds wrote:
> On Fri, May 2, 2014 at 4:53 PM, Andy Lutomirski wrote:
>> On my box, this saves about 100ns on each interrupt and trap that
>> happens while running in kernel space. This speeds up my kernel_pf
>> microbenchmark by about 17%.
>
> Btw, would you
On 05/02/2014 09:32 PM, Linus Torvalds wrote:
On Fri, May 2, 2014 at 4:53 PM, Andy Lutomirski l...@amacapital.net wrote:
On my box, this saves about 100ns on each interrupt and trap that
happens while running in kernel space. This speeds up my kernel_pf
microbenchmark by about 17%.
Btw,
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see a workload which would genuinely benefit before
adding more complexity. Now... if we can determine that it doesn't harm
anything and would solve the NMI nesting problem cleaner than the
current
On Fri, May 2, 2014 at 11:12 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/02/2014 09:32 PM, Linus Torvalds wrote:
At least as a proof-of-concept, having a code sequence in user mode
trampoline that does
popq %rsi
popq %r11
retq $128
and building up a stack in user space at
On 05/03/2014 06:54 AM, Linus Torvalds wrote:
On Fri, May 2, 2014 at 11:12 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/02/2014 09:32 PM, Linus Torvalds wrote:
At least as a proof-of-concept, having a code sequence in user mode
trampoline that does
popq %rsi
popq %r11
retq $128
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see a workload which would genuinely benefit before
adding more complexity. Now... if we can determine that it doesn't harm
anything and would solve the
On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see a workload which would genuinely benefit before
adding more complexity. Now...
On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski l...@amacapital.net wrote:
On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see a
Not for return from NMIs themselves, to be sure
On May 3, 2014 4:51:37 PM PDT, Andy Lutomirski l...@amacapital.net wrote:
On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin
We have to do that anyway to deal with 16- and 32-bit userspace return.
On May 3, 2014 5:31:41 PM PDT, Andy Lutomirski l...@amacapital.net wrote:
On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski l...@amacapital.net
wrote:
On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On
On Fri, May 2, 2014 at 4:53 PM, Andy Lutomirski wrote:
> On my box, this saves about 100ns on each interrupt and trap that
> happens while running in kernel space. This speeds up my kernel_pf
> microbenchmark by about 17%.
Btw, would you mind _trying_ to do a similar trick for the "return to
On 05/02/2014 04:53 PM, Andy Lutomirski wrote:
> On my box, this saves about 100ns on each interrupt and trap that
> happens while running in kernel space. This speeds up my kernel_pf
> microbenchmark by about 17%.
>
> Signed-off-by: Andy Lutomirski
I'd really like to see a workload which
On my box, this saves about 100ns on each interrupt and trap that
happens while running in kernel space. This speeds up my kernel_pf
microbenchmark by about 17%.
Signed-off-by: Andy Lutomirski
---
Changes from v1:
- Comment fix *facepalm*
Changes from the RFC:
- Much better comments
-
On my box, this saves about 100ns on each interrupt and trap that
happens while running in kernel space. This speeds up my kernel_pf
microbenchmark by about 17%.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
Changes from v1:
- Comment fix *facepalm*
Changes from the RFC:
- Much
On 05/02/2014 04:53 PM, Andy Lutomirski wrote:
On my box, this saves about 100ns on each interrupt and trap that
happens while running in kernel space. This speeds up my kernel_pf
microbenchmark by about 17%.
Signed-off-by: Andy Lutomirski l...@amacapital.net
I'd really like to see a
On Fri, May 2, 2014 at 4:53 PM, Andy Lutomirski l...@amacapital.net wrote:
On my box, this saves about 100ns on each interrupt and trap that
happens while running in kernel space. This speeds up my kernel_pf
microbenchmark by about 17%.
Btw, would you mind _trying_ to do a similar trick for
26 matches
Mail list logo
