[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <mhng-5a4880f5-926c-4087-8bb9-b6c09fd4e288@palmer-ri-x1c9>
Date: Wed, 06 Dec 2023 09:56:15 -0800 (PST)
From: Palmer Dabbelt <palmer@...belt.com>
To: parri.andrea@...il.com
CC: mathieu.desnoyers@...icios.com, paulmck@...nel.org,
Paul Walmsley <paul.walmsley@...ive.com>,
aou@...s.berkeley.edu, mmaas@...gle.com, hboehm@...gle.com,
striker@...ibm.com, charlie@...osinc.com, rehn@...osinc.com,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] membarrier: riscv: Provide core serializing command
On Wed, 06 Dec 2023 09:42:44 PST (-0800), parri.andrea@...il.com wrote:
>> > The final version of this fix will likely depend on some machinery/code
>> > introduced by 3ccfebedd8cf54 ("powerpc, membarrier: Skip memory barrier
>> > in switch_mm()"); but, yes, nothing we can't safely adjust I think.
>>
>> Ya, I guess we'll have to look to know for sure but hopefully it's
>> manageable.
>
> Absolutely. One approach would be to follow what PowerPC did: AFAIU, before
> 3ccfebedd8cf54 membarrier/powerpc used to hard code the required barrier in
> in finish_task_switch(), "masking" it as an smp_mb__after_unlock_lock(); riscv
> could use a similar approach (though with a different/new mask function).
IIRC we patterned our MMIOWB/after-spinlock barriers after PPC, so
that's probably a good place to start here as well.
> Alternatively, we could maybe keep the barrier in switch_mm().
>
> But let me complete and send out v2 with the fix at stake... this should give
> us a more concrete basis to discuss about these matters.
>
> Andrea
Powered by blists - more mailing lists