On 13/03/2025 2:19 pm, Jan Beulich wrote: > On 13.03.2025 14:58, Andrew Cooper wrote: >> On 13/03/2025 1:38 pm, Jan Beulich wrote: >>> There's no need for each arch to invoke it directly, and there's no need >>> for having a stub either. With the present placement of the calls to >>> init_constructors() it can easily be a constructor itself. >>> >>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> This has a side effect of wiring it up on RISC-V and PPC, as they >> process constructors. It looks safe enough, but have you double checked? > I've been looking at this differently: For both it can't be right for the > function to _not_ be called.
Eventually, sure. But they're both in the early bringup stage, still getting the basics working. So really, the question is "does this (not) cause CI to explode". In c/s 8c3ab4ffa953 I noted it was easy to make CONFIG_TRACEBUFFER build for PPC, but I didn't try running init_trace_bufs(). Anyway, I've kicked off https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1715210166 to check. > >> However, the position and logic during init is nonsense, I think. >> >> It registers a cpu notifier which only does spin_lock_init() on a >> per-cpu variable, which I think only works today because 0 is the init >> value. >> >> alloc_trace_bufs() on the other hand has a for_each_online_cpu() loop >> because it's too late and ought to be a presmp_initcall(). >> >> Also the allocations could be NUMA-local for all but the biggest of >> servers (given the 16T upper limit because there are raw uint32_t's >> involved in the protocol). > ... there's certainly further room for improvement, init_trace_bufs() > is all just "normal" code, which was already built before. > > If there are missing pieces to make trace buffers fully working there, > that's no different from before the patch. > > As to alloc_trace_bufs() - that has a 2nd caller, so converting to > presmp_initcall() may not buy us all that much. Another bug I've realised is that this fails if we hot-online new CPUs later, because tb_init will be set but nothing allocated on the new CPUs. > >> I'm tempted to ack this on the basis that it is an improvement, but a /* >> TODO this is all mad, please fix */ wouldn't go amiss either. > I understand you like adding such comments; I, however, at least > sometimes (e.g.) don't. Especially without at least outlining what > would need doing. Just saying "this is all mad" doesn't really help > very much. I was being somewhat flippant. But a /* TODO, try and make this a presmp_initcall() to improve alloc_trace_bufs() */ would be fine. ~Andrew
