linux-kernel - Re: [PATCH 2/7] rcu: limit PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87zfn1jk43.fsf@oracle.com>
Date: Fri, 18 Oct 2024 12:18:04 -0700
From: Ankur Arora <ankur.a.arora@...cle.com>
To: paulmck@...nel.org
Cc: Ankur Arora <ankur.a.arora@...cle.com>,
        Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, mingo@...nel.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        vschneid@...hat.com, frederic@...nel.org, efault@....de
Subject: Re: [PATCH 2/7] rcu: limit PREEMPT_RCU configurations

Paul E. McKenney <paulmck@...nel.org> writes:

> On Thu, Oct 17, 2024 at 03:50:46PM -0700, Ankur Arora wrote:
>> Sebastian Andrzej Siewior <bigeasy@...utronix.de> writes:
>> > On 2024-10-15 15:13:46 [-0700], Ankur Arora wrote:
>> >> Sebastian Andrzej Siewior <bigeasy@...utronix.de> writes:
>> >>
[ ... ]
>> Sure. But, that's just begging the question.
>>
>> We want _NONE and _VOLUNTARY to go away because keeping cond_resched()
>> around incurs a cost.
>
> When you say "go away", do you mean for your use cases?  Or globally?

When I say "want _ to go away" I mean: cond_resched() is deleterious
to performance since you are forced to have code which can do the
rescheduling check synchronously -- when this could easily be done
asynchronously (as the non voluntary models do).

And this either means poor performance (ex. in the page zeroing code
where it would be more optimal to work on continguous ranges) or
gyrations like the ones that xen_pv_evtchn_do_upcall() and the
Xen hypervisor have to go through.

And, as we've discussed before, the cond_resched() interface, while it
works, is not ideal.

Also, a man can dream!

--
ankur