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  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:	Fri, 8 Aug 2014 18:01:28 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	mingo@...nel.org, laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, tglx@...utronix.de, dhowells@...hat.com,
	edumazet@...gle.com, dvhart@...ux.intel.com, fweisbec@...il.com,
	bobby.prani@...il.com, masami.hiramatsu.pt@...achi.com
Subject: Re: [PATCH v3 tip/core/rcu 3/9] rcu: Add synchronous grace-period
 waiting for RCU-tasks

On Fri, Aug 08, 2014 at 11:39:49AM -0400, Steven Rostedt wrote:
> > > > Sure, I get that part. What I was getting as is _WHY_ you need
> > > > call_rcu_task(), why isn't synchronize_tasks() good enough?
> > > 
> > > Oh, because that synchronize_tasks() may take minutes. And that means
> > > we wont be able to return for a long time. The only thing I can really
> > > see using call_rcu_task() is something that needs to free its data. Why
> > > wait around when all you're going to do is call free? It's basically
> > > just a garbage collector.
> > 
> > Well the waiting has the advantage of being a natural throttle on the
> > amount of memory tied up in the whole scheme.
> 
> Yeah, but it would suck if you do "echo nop > current_tracer" while
> running something that is preventing a task to unload, and have to wait
> a few minutes for that to return.

> > You said 10e3 order things, I then give you a small 32bit arm system.

> Honestly, to allocate 1000 different callbacks now, requires allocating
> 1000 different ops, which are much larger than a single trampoline.
> Right now, the only way to do that is to create a 1000 ftrace
> instances, and those creates a 1000 directories, would would include
> 1000 event directories, each having its own dentry for each event
> (around 900).
> 
> I don't think we need to worry about this use to work on a small arm 32
> bit system and it doesn't work now. The difference in memory
> consumption is not that much.

Well, see the _BIG_ difference is that currently, when I do nop >
current_tracer all that memory is instantly freed again.

With the proposed scheme, if I setup state, reconsider, destroy state,
try again, and generally muck about I can tie up unspecified amounts of
memory.

And being the bumbling idiot that I am, that's actually fairly typical
of how I end up tracing. There's no neat and tidy, I trace something,
look at the trace, script a little, muck about with the settings and
goto 1.


In any case, I think I now fully understand what you're trying to do,
just not sure its all win.

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists