On Thu, Feb 26, 2015 at 7:21 AM, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 3:42 AM, Ingo Molnar wrote:
>>
>> * Andy Lutomirski wrote:
>>
>>> >> I added that in and applied this patch.
>>> >
>>> > So this is not just slightly buggy, it's fundamentally
>>> > wrong as well as it removes the
On Thu, Feb 26, 2015 at 3:42 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> >> I added that in and applied this patch.
>> >
>> > So this is not just slightly buggy, it's fundamentally
>> > wrong as well as it removes the possibility of an RSP
>> > value optimization from the 64-bit path
* Andy Lutomirski wrote:
> >> I added that in and applied this patch.
> >
> > So this is not just slightly buggy, it's fundamentally
> > wrong as well as it removes the possibility of an RSP
> > value optimization from the 64-bit path, see my
> > previous mail.
>
> This is just trying to che
On Wed, Feb 25, 2015 at 1:45 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> - BUG_ON(((current_stack_pointer() ^
>> this_cpu_read_stable(kernel_stack))
>> + BUG_ON(((current_stack_pointer() ^
>> +(this_cpu_read_stable(kernel_stack) - 1))
>> &
* Denys Vlasenko wrote:
> > The decision on how exactly we should fix
> > KERNEL_STACK_OFFSET (set it to SIZEOF_PTREGS or to
> > zero) depends on whether we switch to using PUSHes, or
> > not. What do you think?
Yes.
> A data point. I implemented push-based creation of
> pt_regs and benchm
On 02/25/2015 01:48 PM, Denys Vlasenko wrote:
> On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar wrote:
>> But the fix should be to not touch RSP in SAVE_ARGS, to
>> keep percpu::kernel_stack as an optimized entry point -
>> with KERNEL_STACK_OFFSET pointing to.
>>
>> So NAK - this should be fixed for
On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> PER_CPU_VAR(kernel_stack) was set up in a way where it
>> points five stack slots below the top of stack.
>>
>> Presumably, it was done to avoid one "sub $5*8,%rsp" in
>> syscall/sysenter code paths, where iret f
* Andy Lutomirski wrote:
> - BUG_ON(((current_stack_pointer() ^ this_cpu_read_stable(kernel_stack))
> + BUG_ON(((current_stack_pointer() ^
> +(this_cpu_read_stable(kernel_stack) - 1))
> & ~(THREAD_SIZE - 1)) != 0);
>
> preempt_count_sub(HARDIR
* Denys Vlasenko wrote:
> PER_CPU_VAR(kernel_stack) was set up in a way where it
> points five stack slots below the top of stack.
>
> Presumably, it was done to avoid one "sub $5*8,%rsp" in
> syscall/sysenter code paths, where iret frame needs to be
> created by hand.
>
> Ironically, none
On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko wrote:
> PER_CPU_VAR(kernel_stack) was set up in a way where it points
> five stack slots below the top of stack.
>
> Presumably, it was done to avoid one "sub $5*8,%rsp"
> in syscall/sysenter code paths, where iret frame needs to be
> created by ha
On 02/24/2015 08:30 PM, Steven Rostedt wrote:
> On Tue, 24 Feb 2015 19:51:33 +0100
> Denys Vlasenko wrote:
>
>> PER_CPU_VAR(kernel_stack) was set up in a way where it points
>> five stack slots below the top of stack.
>>
>> Presumably, it was done to avoid one "sub $5*8,%rsp"
>> in syscall/sysent
On Tue, 24 Feb 2015 19:51:33 +0100
Denys Vlasenko wrote:
> PER_CPU_VAR(kernel_stack) was set up in a way where it points
> five stack slots below the top of stack.
>
> Presumably, it was done to avoid one "sub $5*8,%rsp"
> in syscall/sysenter code paths, where iret frame needs to be
> created by
PER_CPU_VAR(kernel_stack) was set up in a way where it points
five stack slots below the top of stack.
Presumably, it was done to avoid one "sub $5*8,%rsp"
in syscall/sysenter code paths, where iret frame needs to be
created by hand.
Ironically, none of them benefit from this optimization,
since
13 matches
Mail list logo
