[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFTL4hw=OorY4=Y4RRQv5qZVZCmv201dpNECGH37neDArc4wpg@mail.gmail.com>
Date: Fri, 14 Dec 2012 00:10:09 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Gilad Ben-Yossef <gilad@...yossef.com>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Li Zhong <zhong@...ux.vnet.ibm.com>
Subject: Re: [PATCH] context_tracking: Add comments on interface and internals
2012/12/14 Andrew Morton <akpm@...ux-foundation.org>:
> On Thu, 13 Dec 2012 23:50:23 +0100
> Frederic Weisbecker <fweisbec@...il.com> wrote:
>
>> >
>> >> + * This call supports re-entrancy.
>> >
>> > Presumably the explanation for user_exit() applies here.
>>
>> Not sure what you mean here.
>
> It's unclear what it means to say "user_enter() supports reentrancy".
> I mean, zillions of kernel functions are surely reentrant - so what?
> It appears that you had something in mind when pointing this out, but
> what was it? The comment over user_exit() appears to tell us.
Ah ok. Yeah indeed, the fact user_exit() is reentrant is very
important because I have precise usecases in mind. For user_enter() I
don't, so probably I don't need to inform about it.
>
>> > It's mainly this bit which makes me wonder why the code is in lib/. Is
>> > there any conceivable prospect that any other subsystem will use this
>> > code for anything?
>>
>> So that's because of that cputime accounting on dynticks CPUs which
>> will need to know about user/kernel transitions. I'm preparing that
>> for the 3.9 merge window.
>
> Oh. That's really the entire reason for the patch and should have been
> in the changelog!
I mentioned it in the changelog:
commit 91d1aa43d30505b0b825db8898ffc80a8eca96c7 "context_tracking: New
context tracking susbsystem"
"""
We need to pull this up from RCU into this new level of indirection
because this tracking is also going to be used to implement an "on
demand" generic virtual cputime accounting. A necessary step to
shutdown the tick while still accounting the cputime.
"""
Another reason, more implicit this time, was to avoid that RCU handles
those reentrancy things and context tracking all around by itself.
--
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/
Powered by blists - more mailing lists