Prev: [RFC PATCH V2] core_pattern: fix long parameters was truncated by core_pattern handler
Next: Bluetooth disabled after resume
From: Peter Zijlstra on 2 Aug 2010 08:30
On Sun, 2010-08-01 at 14:36 +0900, Hitoshi Mitake wrote:
> I want to make lockdep production kernel feature with dynamic
> patching.

Not really feasible. Note that enabling lockdep grows the size of
spinlock_t (and others) quite significantly.

Then there is the problem that you need to pass all tasks through some
quiesent state in order to enable lockdep (there must be a guarantee of
no locks held).

Now, we could possibly make it all work, but I'm not at all convinced we
want to pay the price, which is a much _much_ more complex
infrastructure.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Hitoshi Mitake on 3 Aug 2010 03:40
On 08/02/10 21:23, Peter Zijlstra wrote:
> On Sun, 2010-08-01 at 14:36 +0900, Hitoshi Mitake wrote:
>> I want to make lockdep production kernel feature with dynamic
>> patching.
>
> Not really feasible. Note that enabling lockdep grows the size of
> spinlock_t (and others) quite significantly.
>
> Then there is the problem that you need to pass all tasks through some
> quiesent state in order to enable lockdep (there must be a guarantee of
> no locks held).
>
> Now, we could possibly make it all work, but I'm not at all convinced we
> want to pay the price, which is a much _much_ more complex
> infrastructure.
>
>

I have to agree with the problem of huge cost you mentioned above.

But, I believe that
- lock validation
- lock tracing
- in kernel light weight lock usage statistics
should be divided into individual features, at least.
And tracing and statistics should be available for production kernel,
ideally.

How do you think about this point?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 3 Aug 2010 04:10
On Tue, 2010-08-03 at 16:37 +0900, Hitoshi Mitake wrote:
> But, I believe that
> - lock validation
> - lock tracing
> - in kernel light weight lock usage statistics
> should be divided into individual features, at least.
> And tracing and statistics should be available for production kernel,
> ideally.
>
> How do you think about this point?

Both the lock usage and lock validation use the lock classification
scheme and thus require the bloated lock structures, and hence I don't
think its at all reasonable to do that runtime.

lock tracing could possibly be done by patching all lock sites, but we'd
have to be somewhat careful there too not to make the whole spinlock
code even worse than it already is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [RFC PATCH V2] core_pattern: fix long parameters was truncated by core_pattern handler
Next: Bluetooth disabled after resume