[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b98b7795-070a-4d9c-9599-445c2ff55fd7@linux.ibm.com>
Date: Wed, 20 Nov 2024 21:03:11 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Ankur Arora <ankur.a.arora@...cle.com>
Cc: mpe@...erman.id.au, linuxppc-dev@...ts.ozlabs.org, npiggin@...il.com,
christophe.leroy@...roup.eu, maddy@...ux.ibm.com,
linux-kernel@...r.kernel.org, vschneid@...hat.com,
mark.rutland@....com
Subject: Re: [PATCH v2 2/2] powerpc: Large user copy aware of full:rt:lazy
preemption
On 11/20/24 13:33, Sebastian Andrzej Siewior wrote:
> On 2024-11-19 13:08:31 [-0800], Ankur Arora wrote:
>>
>> Shrikanth Hegde <sshegde@...ux.ibm.com> writes:
>>
Thanks Ankur and Sebastian for taking a look.
>>> Large user copy_to/from (more than 16 bytes) uses vmx instructions to
>>> speed things up. Once the copy is done, it makes sense to try schedule
>>> as soon as possible for preemptible kernels. So do this for
>>> preempt=full/lazy and rt kernel.
>>
>> Note that this check will also fire for PREEMPT_DYNAMIC && preempt=none.
>> So when power supports PREEMPT_DYNAMIC this will need to change
>> to preempt_model_*() based checks.
Yes. This and return to kernel both needs to change when PowerPC support PREEMPT_DYNAMIC.
I have a patch in work in which I essentially do check for the preemption model.
Either below or based on static key.
- if (IS_ENABLED(CONFIG_PREEMPTION) && need_resched())
+ if (preempt_model_preemptible() && need_resched())
+mark +valentin
More looking into how PREEMPPT_DYNAMIC works with static key, I have one query.
This is more on PREEMPT_DYNAMIC than anything to with LAZY.
I see many places use static_key based check instead of using preempt_model_preemptible such as
dynamic_preempt_schedule, is it because static_key is faster?
On the other hand, using preempt_model_preemptible could make the code simpler.
>>
>>> Not checking for lazy bit here, since it could lead to unnecessary
>>> context switches.
>>
>> Maybe:
>> Not checking for lazy bit here, since we only want to schedule when
>> a context switch is imminently required.
>
> Isn't his behaviour here exactly what preempt_enable() would do?
> If the LAZY bit is set, it is delayed until return to userland or an
> explicit schedule() because it is done. If this LAZY bit turned into an
> actual scheduling request then it is acted upon.
>
> Sebastian
Powered by blists - more mailing lists