On Thu, 21 Mar 2019 21:03:16 +0100 Peter Zijlstra <pet...@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
