On 14.02.24 00:28, Suren Baghdasaryan wrote:
On Tue, Feb 13, 2024 at 3:22 PM David Hildenbrand <david@xxxxxxxxxx> wrote:
On 14.02.24 00:12, Kent Overstreet wrote:
On Wed, Feb 14, 2024 at 12:02:30AM +0100, David Hildenbrand wrote:
On 13.02.24 23:59, Suren Baghdasaryan wrote:
On Tue, Feb 13, 2024 at 2:50 PM Kent Overstreet
<kent.overstreet@xxxxxxxxx> wrote:
On Tue, Feb 13, 2024 at 11:48:41PM +0100, David Hildenbrand wrote:
On 13.02.24 23:30, Suren Baghdasaryan wrote:
On Tue, Feb 13, 2024 at 2:17 PM David Hildenbrand <david@xxxxxxxxxx> wrote:
On 13.02.24 23:09, Kent Overstreet wrote:
On Tue, Feb 13, 2024 at 11:04:58PM +0100, David Hildenbrand wrote:
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.
I'd rather not delay for more bikeshedding. Before agreeing to LSF I'd
need to see a serious proposl - what we had at the last LSF was people
jumping in with half baked alternative proposals that very much hadn't
been thought through, and I see no need to repeat that.
Like I mentioned, there's other work gated on this patchset; if people
want to hold this up for more discussion they better be putting forth
something to discuss.
I'm thinking of ways on how to achieve Michal's request: "as long as
there is a wider agreement from the MM community". If we can achieve
that without LSF, great! (a bi-weekly MM meeting might also be an option)
There will be a maintenance burden even with the cleanest proposed
approach.
Yes.
We worked hard to make the patchset as clean as possible and
if benefits still don't outweigh the maintenance cost then we should
probably stop trying.
Indeed.
At LSF/MM I would rather discuss functonal
issues/requirements/improvements than alternative approaches to
instrument allocators.
I'm happy to arrange a separate meeting with MM folks if that would
help to progress on the cost/benefit decision.
Note that I am only proposing ways forward.
If you think you can easily achieve what Michal requested without all that,
good.
He requested something?
Yes, a cleaner instrumentation. Unfortunately the cleanest one is not
possible until the compiler feature is developed and deployed. And it
still would require changes to the headers, so don't think it's worth
delaying the feature for years.
I was talking about this: "I can live with all the downsides of the proposed
implementationas 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".
I certainly cannot be motivated at this point to review and ack this,
unfortunately too much negative energy around here.
David, this kind of reaction is exactly why I was telling Andrew I was
going to submit this as a direct pull request to Linus.
This is an important feature; if we can't stay focused ot the technical
and get it done that's what I'll do.
Kent, I started this with "Would it make sense" in an attempt to help
Suren and you to finally make progress with this, one way or the other.
I know that there were ways in the past to get the MM community to agree
on such things.
I tried to be helpful, finding ways *not having to* bypass the MM
community to get MM stuff merged.
The reply I got is mostly negative energy.
So you don't need my help here, understood.
But I will fight against any attempts to bypass the MM community.
Well, I'm definitely not trying to bypass the MM community, that's why
this patchset is posted. Not sure why people can't voice their opinion
on the benefit/cost balance of the patchset over the email... But if a
meeting would be more productive I'm happy to set it up.
If you can get the acks without any additional meetings, great. The
replies from Pasha and Johannes are encouraging, let's hope core
memory-allocator people will voice their opinion here.
If you come to the conclusion that another meeting would help getting
maintainers's attention and sorting out some of the remaining concerns,
feel free to schedule a meeting with Dave R. I suspect only the slot
next week is already taken. In the past, we also had "special" meetings
just for things to make progress faster.
If you're looking for ideas on what the agenda of such a meeting could
look like, I'll happily discuss that with you off-list.
v2 was more than 3 months ago. If it's really about minor details here,
waiting another 3 months for LSF/MM is indeed not reasonable.
Myself, I'll be happy not having to sit through another LSF/MM session
of that kind. The level of drama is exceptional and I'm hoping it won't
be the new norm in the MM space.
Good luck!
--
Cheers,
David / dhildenb
