linux-kernel - Re: [PATCH v2 tip/core/rcu 0/10] RCU-tasks implementation

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]

Date:	Thu, 31 Jul 2014 09:19:02 -0700
From:	josh@...htriplett.org
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
	fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH v2 tip/core/rcu 0/10] RCU-tasks implementation

On Wed, Jul 30, 2014 at 05:39:14PM -0700, Paul E. McKenney wrote:
> This series provides a prototype of an RCU-tasks implementation, which has
> been requested to assist with tramopoline removal.  This flavor of RCU
> is task-based rather than CPU-based, and has voluntary context switch,
> usermode execution, and the idle loops as its only quiescent states.
> This selection of quiescent states ensures that at the end of a grace
> period, there will no longer be any tasks depending on a trampoline that
> was removed before the beginning of that grace period.  This works because
> such trampolines do not contain function calls, do not contain voluntary
> context switches, do not switch to usermode, and do not switch to idle.

I'm concerned about the amount of system overhead this introduces.
Polling for holdout tasks seems quite excessive.  If I understand the
intended use case correctly, the users of this will want to free
relatively small amounts of memory; thus, waiting a while to do so seems
fine, especially if the system isn't under any particular memory
pressure.

Thus, rather than polling, could you simply flag the holdout
tasks, telling the scheduler "hey, next time you don't have anything
better to do..."?  Then don't bother with them again unless the system
runs low on memory and asks you to free some.  (And mandate that you can
only use this to free memory rather than for any other purpose.)

Also, ideally this should remain entirely optional; nothing in the core
kernel should depend on it.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/