Re: [PATCH v3 00/35] Memory allocation profiling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13.02.24 22:58, Suren Baghdasaryan wrote:
On Tue, Feb 13, 2024 at 4:24 AM Michal Hocko <mhocko@xxxxxxxx> wrote:

On Mon 12-02-24 13:38:46, Suren Baghdasaryan wrote:
[...]
We're aiming to get this in the next merge window, for 6.9. The feedback
we've gotten has been that even out of tree this patchset has already
been useful, and there's a significant amount of other work gated on the
code tagging functionality included in this patchset [2].

I suspect it will not come as a surprise that I really dislike the
implementation proposed here. I will not repeat my arguments, I have
done so on several occasions already.

Anyway, I didn't go as far as to nak it even though I _strongly_ believe
this debugging feature will add a maintenance overhead for a very long
time. I can live with all the downsides of the proposed implementation
_as long as_ there is a wider agreement from the MM community as this is
where the maintenance cost will be payed. So far I have not seen (m)any
acks by MM developers so aiming into the next merge window is more than
little rushed.

We tried other previously proposed approaches and all have their
downsides without making maintenance much easier. Your position is
understandable and I think it's fair. Let's see if others see more
benefit than cost here.

Would it make sense to discuss that at LSF/MM once again, especially covering why proposed alternatives did not work out? LSF/MM is not "too far" away (May).

I recall that the last LSF/MM session on this topic was a bit unfortunate (IMHO not as productive as it could have been). Maybe we can finally reach a consensus on this.

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux