On 06/18/2015 11:31 AM, Ingo Molnar wrote:
>> If it takes, say, 20 cycles to pull data from e.g. L3 cache to ECX,
>> then SYSRET can't possibly complete sooner than in 20 cycles.
>
> Yeah, that's true, but my point is: SYSRET has to do a lot of other things
> (permission checks, loading the user
* Denys Vlasenko wrote:
> On 06/15/2015 10:20 PM, Ingo Molnar wrote:
> >> Actually, ecx and r11 need to be loaded first. They are not so much
> >> "restored"
> >> as "prepared for SYSRET insn". Every cycle lost in loading these delays
> >> SYSRET.
> >> [...]
> >
> > So in the typical case
* Denys Vlasenko dvlas...@redhat.com wrote:
On 06/15/2015 10:20 PM, Ingo Molnar wrote:
Actually, ecx and r11 need to be loaded first. They are not so much
restored
as prepared for SYSRET insn. Every cycle lost in loading these delays
SYSRET.
[...]
So in the typical case they
On 06/18/2015 11:31 AM, Ingo Molnar wrote:
If it takes, say, 20 cycles to pull data from e.g. L3 cache to ECX,
then SYSRET can't possibly complete sooner than in 20 cycles.
Yeah, that's true, but my point is: SYSRET has to do a lot of other things
(permission checks, loading the user mode
On 06/15/2015 10:20 PM, Ingo Molnar wrote:
>> Actually, ecx and r11 need to be loaded first. They are not so much
>> "restored"
>> as "prepared for SYSRET insn". Every cycle lost in loading these delays
>> SYSRET.
>> [...]
>
> So in the typical case they will still be cached, and so their max
* Denys Vlasenko wrote:
> On 06/14/2015 10:40 AM, Ingo Molnar wrote:
> >
> > * Denys Vlasenko wrote:
> >
> >>+8b 74 24 68mov0x68(%rsp),%esi
> >>+8b 7c 24 70mov0x70(%rsp),%edi
> >>+8b 54 24 60mov0x60(%rsp),%edx
> >
> > Btw., could
* Denys Vlasenko dvlas...@redhat.com wrote:
On 06/14/2015 10:40 AM, Ingo Molnar wrote:
* Denys Vlasenko dvlas...@redhat.com wrote:
+8b 74 24 68mov0x68(%rsp),%esi
+8b 7c 24 70mov0x70(%rsp),%edi
+8b 54 24 60mov0x60(%rsp),%edx
On 06/15/2015 10:20 PM, Ingo Molnar wrote:
Actually, ecx and r11 need to be loaded first. They are not so much
restored
as prepared for SYSRET insn. Every cycle lost in loading these delays
SYSRET.
[...]
So in the typical case they will still be cached, and so their max latency
On 06/14/2015 10:40 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> +8b 74 24 68mov0x68(%rsp),%esi
>> +8b 7c 24 70mov0x70(%rsp),%edi
>> +8b 54 24 60mov0x60(%rsp),%edx
>
> Btw., could you (in another patch) order the
* Denys Vlasenko wrote:
> +8b 74 24 68mov0x68(%rsp),%esi
> +8b 7c 24 70mov0x70(%rsp),%edi
> +8b 54 24 60mov0x60(%rsp),%edx
Btw., could you (in another patch) order the restoration properly, by pt_regs
memory order, where
* Denys Vlasenko dvlas...@redhat.com wrote:
+8b 74 24 68mov0x68(%rsp),%esi
+8b 7c 24 70mov0x70(%rsp),%edi
+8b 54 24 60mov0x60(%rsp),%edx
Btw., could you (in another patch) order the restoration properly, by pt_regs
memory
On 06/14/2015 10:40 AM, Ingo Molnar wrote:
* Denys Vlasenko dvlas...@redhat.com wrote:
+8b 74 24 68mov0x68(%rsp),%esi
+8b 7c 24 70mov0x70(%rsp),%edi
+8b 54 24 60mov0x60(%rsp),%edx
Btw., could you (in another patch) order the
On Tue, Jun 9, 2015 at 12:18 PM, Denys Vlasenko wrote:
> On 06/09/2015 09:11 PM, Andy Lutomirski wrote:
>> On Tue, Jun 9, 2015 at 12:03 PM, Denys Vlasenko wrote:
>>> On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko
wrote:
> This
On 06/09/2015 09:11 PM, Andy Lutomirski wrote:
> On Tue, Jun 9, 2015 at 12:03 PM, Denys Vlasenko wrote:
>> On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
>>> On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko wrote:
This doesn't change much, but this uses shorter 32-bit insns:
On Tue, Jun 9, 2015 at 12:03 PM, Denys Vlasenko wrote:
> On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
>> On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko wrote:
>>> This doesn't change much, but this uses shorter 32-bit insns:
>>>
>>> -48 8b 74 24 68 mov0x68(%rsp),%rsi
>>>
On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
> On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko wrote:
>> This doesn't change much, but this uses shorter 32-bit insns:
>>
>> -48 8b 74 24 68 mov0x68(%rsp),%rsi
>> -48 8b 7c 24 70 mov0x70(%rsp),%rdi
>>
On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko wrote:
> This doesn't change much, but this uses shorter 32-bit insns:
>
> -48 8b 74 24 68 mov0x68(%rsp),%rsi
> -48 8b 7c 24 70 mov0x70(%rsp),%rdi
> -48 8b 54 24 60 mov0x60(%rsp),%rdx
>
This doesn't change much, but this uses shorter 32-bit insns:
-48 8b 74 24 68 mov0x68(%rsp),%rsi
-48 8b 7c 24 70 mov0x70(%rsp),%rdi
-48 8b 54 24 60 mov0x60(%rsp),%rdx
+8b 74 24 68mov0x68(%rsp),%esi
+8b 7c
This doesn't change much, but this uses shorter 32-bit insns:
-48 8b 74 24 68 mov0x68(%rsp),%rsi
-48 8b 7c 24 70 mov0x70(%rsp),%rdi
-48 8b 54 24 60 mov0x60(%rsp),%rdx
+8b 74 24 68mov0x68(%rsp),%esi
+8b 7c
On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko dvlas...@redhat.com wrote:
This doesn't change much, but this uses shorter 32-bit insns:
-48 8b 74 24 68 mov0x68(%rsp),%rsi
-48 8b 7c 24 70 mov0x70(%rsp),%rdi
On Tue, Jun 9, 2015 at 12:03 PM, Denys Vlasenko dvlas...@redhat.com wrote:
On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko dvlas...@redhat.com wrote:
This doesn't change much, but this uses shorter 32-bit insns:
-48 8b 74 24 68
On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko dvlas...@redhat.com wrote:
This doesn't change much, but this uses shorter 32-bit insns:
-48 8b 74 24 68 mov0x68(%rsp),%rsi
-48 8b 7c 24 70 mov0x70(%rsp),%rdi
-48 8b 54 24 60 mov
On Tue, Jun 9, 2015 at 12:18 PM, Denys Vlasenko dvlas...@redhat.com wrote:
On 06/09/2015 09:11 PM, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 12:03 PM, Denys Vlasenko dvlas...@redhat.com wrote:
On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko
On 06/09/2015 09:11 PM, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 12:03 PM, Denys Vlasenko dvlas...@redhat.com wrote:
On 06/09/2015 09:01 PM, Andy Lutomirski wrote:
On Tue, Jun 9, 2015 at 11:54 AM, Denys Vlasenko dvlas...@redhat.com wrote:
This doesn't change much, but this uses shorter
24 matches
Mail list logo