lkml.org 
[lkml]   [2019]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] tracing/x86: Save CR2 before tracing irqsoff on error_entry
On Thu, 21 Mar 2019 21:03:16 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> Doesn't make sense; you say data, but then talk code and i$.

Ah, you meant d$

>
> Not the point, spinlock_t is 4 bytes, but growns into a monster with
> lockdep on. There are plenty locations where the spinlock and the data
> it protects fit together into a single cacheline, no longer so with
> lockdep on.
>
> Another example is split pte locks, without lockdep they are in struct
> page, with lockdep, they're a separate allocation, adding pointer
> chases.
>
> Also; I do not, and have never done so, understood the desire to have
> this unified kernel. Building another kernel just isn't a problem, esp.
> not if you're doing kernel development to begin with.

It's not for the typical kernel developer like you and me. It's about
shipping to the customers. Shipping multiple kernels is a pain. Lockdep
has some features that can be used in production environments, like
seeing lock contention and irq latency. Most of that code is dependent
on lockdep. Having just tracing of locks and such would be useful. But
that also relies heavily on the lockdep infrastructure.

>
> Making debug code complicated, such that you need to spend more time
> debugging the debug code, just doens't make sense to me either.

Perhaps this can also help clean it up, and organize it. Sometimes
adding features makes the code cleaner (see what RT has done to the
kernel).

-- Steve

\
 
 \ /
  Last update: 2019-03-21 21:12    [W:2.368 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site