Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 01:04:23PM -0800, Andy Lutomirski wrote: > Can we please not rely on any of the active_mm shit? That thing has > really weird semantics and should just die. I don't agree on the weird semantics. Its simply the last user mm. I won't mind seeing it go as it would reduce

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 01:04:23PM -0800, Andy Lutomirski wrote: > Can we please not rely on any of the active_mm shit? That thing has > really weird semantics and should just die. I don't agree on the weird semantics. Its simply the last user mm. I won't mind seeing it go as it would reduce

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 01/25/2018 02:01 PM, Andy Lutomirski wrote: > On Thu, Jan 25, 2018 at 1:57 PM, Andi Kleen wrote: >> Andy Lutomirski writes: >>> >>> That being said, just stashing last_user_mm without any refcounting >>> should be fine. >> >> If last_user_mm is freed and

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 01/25/2018 02:01 PM, Andy Lutomirski wrote: > On Thu, Jan 25, 2018 at 1:57 PM, Andi Kleen wrote: >> Andy Lutomirski writes: >>> >>> That being said, just stashing last_user_mm without any refcounting >>> should be fine. >> >> If last_user_mm is freed and reallocated by a different process, >>

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 1:57 PM, Andi Kleen wrote: > Andy Lutomirski writes: >> >> That being said, just stashing last_user_mm without any refcounting >> should be fine. > > If last_user_mm is freed and reallocated by a different process, > then that would

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 1:57 PM, Andi Kleen wrote: > Andy Lutomirski writes: >> >> That being said, just stashing last_user_mm without any refcounting >> should be fine. > > If last_user_mm is freed and reallocated by a different process, > then that would miss the IPBP incorrectly. > Hmm,

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

Andy Lutomirski writes: > > That being said, just stashing last_user_mm without any refcounting > should be fine. If last_user_mm is freed and reallocated by a different process, then that would miss the IPBP incorrectly. -Andi

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

Andy Lutomirski writes: > > That being said, just stashing last_user_mm without any refcounting > should be fine. If last_user_mm is freed and reallocated by a different process, then that would miss the IPBP incorrectly. -Andi

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 12:46 PM, Peter Zijlstra wrote: > On Thu, Jan 25, 2018 at 11:32:46AM -0800, Tim Chen wrote: >> >> This patch is not ideal as it comes with the caveats that >> patch 2 tries to close. I put it out here to see if it can prompt >> people to come up with

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 12:46 PM, Peter Zijlstra wrote: > On Thu, Jan 25, 2018 at 11:32:46AM -0800, Tim Chen wrote: >> >> This patch is not ideal as it comes with the caveats that >> patch 2 tries to close. I put it out here to see if it can prompt >> people to come up with a better solution.

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 11:32:46AM -0800, Tim Chen wrote: > > This patch is not ideal as it comes with the caveats that > patch 2 tries to close. I put it out here to see if it can prompt > people to come up with a better solution. Keeping active_mm around would > have been cleaner but it looks

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 11:32:46AM -0800, Tim Chen wrote: > > This patch is not ideal as it comes with the caveats that > patch 2 tries to close. I put it out here to see if it can prompt > people to come up with a better solution. Keeping active_mm around would > have been cleaner but it looks

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 01/25/2018 11:34 AM, Arjan van de Ven wrote: >> This patch tries to address the case when we do switch to init_mm >> and back. Do you still have objections to the approach in this >> patch to save the last active mm before switching to init_mm? > > how do you know the last active mm did not go

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 01/25/2018 11:34 AM, Arjan van de Ven wrote: >> This patch tries to address the case when we do switch to init_mm >> and back. Do you still have objections to the approach in this >> patch to save the last active mm before switching to init_mm? > > how do you know the last active mm did not go

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This patch tries to address the case when we do switch to init_mm and back. Do you still have objections to the approach in this patch to save the last active mm before switching to init_mm? how do you know the last active mm did not go away and started a new process with new content? (other

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This patch tries to address the case when we do switch to init_mm and back. Do you still have objections to the approach in this patch to save the last active mm before switching to init_mm? how do you know the last active mm did not go away and started a new process with new content? (other

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 01/25/2018 10:18 AM, Peter Zijlstra wrote: > On Thu, Jan 25, 2018 at 09:04:21AM -0800, Andy Lutomirski wrote: >> I haven't tried to fully decipher the patch, but I think the idea is >> wrong. (I think it's the same wrong idea that Rik and I both had and >> that I got into Linus' tree for a

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 01/25/2018 10:18 AM, Peter Zijlstra wrote: > On Thu, Jan 25, 2018 at 09:04:21AM -0800, Andy Lutomirski wrote: >> I haven't tried to fully decipher the patch, but I think the idea is >> wrong. (I think it's the same wrong idea that Rik and I both had and >> that I got into Linus' tree for a

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 09:04:21AM -0800, Andy Lutomirski wrote: > I haven't tried to fully decipher the patch, but I think the idea is > wrong. (I think it's the same wrong idea that Rik and I both had and > that I got into Linus' tree for a while...) The problem is that it's > not actually

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 09:04:21AM -0800, Andy Lutomirski wrote: > I haven't tried to fully decipher the patch, but I think the idea is > wrong. (I think it's the same wrong idea that Rik and I both had and > that I got into Linus' tree for a while...) The problem is that it's > not actually

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

The idea is simple, do what we do for virt. Don't send IPI's to CPUs that don't need them (in virt's case because the vCPU isn't running, in our case because we're not in fact running a user process), but mark the CPU as having needed a TLB flush. I am really uncomfortable with that idea. You

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

The idea is simple, do what we do for virt. Don't send IPI's to CPUs that don't need them (in virt's case because the vCPU isn't running, in our case because we're not in fact running a user process), but mark the CPU as having needed a TLB flush. I am really uncomfortable with that idea. You

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 8:41 AM, Peter Zijlstra wrote: > On Thu, Jan 25, 2018 at 06:07:07AM -0800, Arjan van de Ven wrote: >> On 1/25/2018 5:50 AM, Peter Zijlstra wrote: >> > On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: >> > > > >> > > > This means that

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 8:41 AM, Peter Zijlstra wrote: > On Thu, Jan 25, 2018 at 06:07:07AM -0800, Arjan van de Ven wrote: >> On 1/25/2018 5:50 AM, Peter Zijlstra wrote: >> > On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: >> > > > >> > > > This means that 'A -> idle -> A'

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 06:07:07AM -0800, Arjan van de Ven wrote: > On 1/25/2018 5:50 AM, Peter Zijlstra wrote: > > On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: > > > > > > > > This means that 'A -> idle -> A' should never pass through switch_mm to > > > > begin with. > > > >

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 06:07:07AM -0800, Arjan van de Ven wrote: > On 1/25/2018 5:50 AM, Peter Zijlstra wrote: > > On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: > > > > > > > > This means that 'A -> idle -> A' should never pass through switch_mm to > > > > begin with. > > > >

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 1/25/2018 5:50 AM, Peter Zijlstra wrote: On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IPI CPUs

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 1/25/2018 5:50 AM, Peter Zijlstra wrote: On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IPI CPUs

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: > > > > This means that 'A -> idle -> A' should never pass through switch_mm to > > begin with. > > > > Please clarify how you think it does. > > > > the idle code does leave_mm() to avoid having to IPI CPUs in deep sleep states

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: > > > > This means that 'A -> idle -> A' should never pass through switch_mm to > > begin with. > > > > Please clarify how you think it does. > > > > the idle code does leave_mm() to avoid having to IPI CPUs in deep sleep states

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IPI CPUs in deep sleep states for a tlb flush. (trust me, that you really want, sequentially IPI's a pile of cores in a

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IPI CPUs in deep sleep states for a tlb flush. (trust me, that you really want, sequentially IPI's a pile of cores in a

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 09:58:20AM +0100, Peter Zijlstra wrote: > On Wed, Jan 24, 2018 at 04:36:41PM -0800, Tim Chen wrote: > > These two patches provide optimization to skip IBPB for this > > commonly encountered scenario: > > We could switch to a kernel idle thread and then back to the original

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Thu, Jan 25, 2018 at 09:58:20AM +0100, Peter Zijlstra wrote: > On Wed, Jan 24, 2018 at 04:36:41PM -0800, Tim Chen wrote: > > These two patches provide optimization to skip IBPB for this > > commonly encountered scenario: > > We could switch to a kernel idle thread and then back to the original

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Wed, Jan 24, 2018 at 04:36:41PM -0800, Tim Chen wrote: > These two patches provide optimization to skip IBPB for this > commonly encountered scenario: > We could switch to a kernel idle thread and then back to the original > process such as: > process A -> idle -> process A > > In such

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On Wed, Jan 24, 2018 at 04:36:41PM -0800, Tim Chen wrote: > These two patches provide optimization to skip IBPB for this > commonly encountered scenario: > We could switch to a kernel idle thread and then back to the original > process such as: > process A -> idle -> process A > > In such

[RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

These two patches provide optimization to skip IBPB for this commonly encountered scenario: We could switch to a kernel idle thread and then back to the original process such as: process A -> idle -> process A In such scenario, we do not have to do IBPB here even though the process is

[RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

These two patches provide optimization to skip IBPB for this commonly encountered scenario: We could switch to a kernel idle thread and then back to the original process such as: process A -> idle -> process A In such scenario, we do not have to do IBPB here even though the process is