[<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