17:01:29 <zbyszek> #startmeeting FESCO (2023-05-16)
17:01:29 <zodbot> Meeting started Tue May 16 17:01:29 2023 UTC.
17:01:29 <zodbot> This meeting is logged and archived in a public location.
17:01:29 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:01:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:29 <zodbot> The meeting name has been set to 'fesco_(2023-05-16)'
17:01:29 <zbyszek> #meetingname fesco
17:01:29 <zodbot> The meeting name has been set to 'fesco'
17:01:29 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:01:29 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:01:32 <zbyszek> #topic init process
17:01:46 <mhayden> .hello2
17:01:47 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:01:48 <mhroncok> .hello churchyard
17:01:51 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:01:59 <nirik> morning
17:02:00 <zbyszek> .hello2
17:02:00 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:02:34 <zbyszek> We're at 4/9
17:03:34 <zbyszek> Eighth_Doctor: meeting
17:03:51 <zbyszek> decathorpe, sgallagh, dcantrell, music: meeting
17:03:59 <Eighth_Doctor> I will not be able to stick around much
17:04:09 <Eighth_Doctor> gotta head out to exam testing
17:04:36 <aleasto> .hello2
17:04:39 <zodbot> aleasto: aleasto 'Alessandro Astone' <ales.astone@gmail.com>
17:04:47 <Eighth_Doctor> .hello ngompa
17:04:48 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:05:14 <zbyszek> OK, should we start? With Neal, we theoretically have quorum…
17:05:23 <zbyszek> But we might not be able to pass anything.
17:05:43 <zbyszek> aleasto: thanks for coming
17:05:49 <zbyszek> aleasto++
17:05:49 <zodbot> zbyszek: Karma for aleasto changed to 1 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
17:06:03 <aleasto> :)
17:06:18 <music[m]> .hello music
17:06:19 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
17:06:27 <mhayden> aleasto++
17:06:27 <zodbot> mhayden: Karma for aleasto changed to 2 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
17:06:32 <zbyszek> OK, so now we have 6.5/9, let's go!
17:06:38 <zbyszek> #topic #2994 Change: BiggerESP
17:06:38 <zbyszek> .fesco 2994
17:06:39 <zodbot> zbyszek: Issue #2994: Change: BiggerESP - fesco - Pagure.io - https://pagure.io/fesco/issue/2994
17:07:09 <decathorpe> hey, I'm also here, will be at my PC in a few minutes.
17:07:14 * nirik was +1 in ticket, still am.
17:07:35 <zbyszek> There were 5 +1 votes in the ticket.
17:08:03 <zbyszek> I'm OK with being overvoted on this. I don't think that this is a terrible change, but also it's just another stop-gap half-solution.
17:08:32 <Eighth_Doctor> I'm worried something will break with making the ESP bigger
17:08:36 <mhroncok> 0. I just got back from PTO and I wasn't abel to keep up with anything fesco much
17:08:36 <nirik> yeah, it is... but we need it until we can do some better longer term one IMHO
17:08:40 <Eighth_Doctor> I'd rather see us figure that out and be able to revert it easily if needed
17:10:19 <zbyszek> I'd like us to just make one bigger partition. But if that causes problems, obviously taht'd be bad. So in this regard, growing the ESP first is a good test.
17:10:50 <Eighth_Doctor> I already know that we have problems with really large ESPs in the cloud EFI firmware
17:11:04 <Eighth_Doctor> and I suspect we're going to have some problems on that front in physical servers
17:11:15 <Eighth_Doctor> and laptops too
17:11:20 <Eighth_Doctor> but we'll find out as we try this
17:12:54 <zbyszek> Eighth_Doctor: you mentioned arm. Was it arm64 or arm32?
17:13:00 <Eighth_Doctor> arm64
17:14:09 <zbyszek> Well, OK. I don't have the energy to fight for something better.
17:14:56 <zbyszek> Should we vote?
17:15:47 <music[m]> I see zbyszek’s point as valid, and several people’s points in favor as valid. A few of you understand this change better than I do. It still seems basically OK overall to me.
17:16:33 <sgallagh> .hi
17:16:33 <zbyszek> Eighth_Doctor: was it with FAT32 or FAT16? Because FAT16 should be good for 4GB, so maybe we don't need FAT32.
17:16:34 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:16:58 <sgallagh> I'm weakly +1 to this. I think there are risks, but there are also risks to doing nothing.
17:17:16 <nirik> perhaps we could do 500 on x86 and less/whatever it is now on arm? but that would be kinda confusing...
17:17:17 <zbyszek> Yeah, doing nothing is the worst option.
17:19:21 <zbyszek> OK. Let's vote.
17:19:28 <zbyszek> PROPOSAL: APPROVE
17:19:37 <mhroncok> 0
17:19:53 <mhayden> +1 (as in the ticket)
17:20:06 <sgallagh> +1
17:20:11 <decathorpe> +1
17:20:11 <music[m]> +1
17:20:24 <zbyszek> Eighth_Doctor?
17:21:49 <zbyszek> (I'd like to vote 0, but that'd be nasty, because there was +5 in the ticket, so we'd fall short purely because of procedural reasons.)
17:22:09 <nirik> +1
17:22:17 <mhroncok> I think we can count +1s from the ticket as well
17:22:25 <zbyszek> I don't think we do this normally.
17:22:28 <zbyszek> 0
17:22:30 <mhroncok> ok
17:22:41 <zbyszek> #agree APPROVED (+5, 2, 0)
17:23:05 <zbyszek> I think we would want to change this, i.e. keep votes from the ticket unless revoked, but that's a separate discussion.
17:23:15 <zbyszek> #topic #2993 Change: Increase vm.max_map_count value
17:23:15 <zbyszek> .fesco 2993
17:23:16 <zodbot> zbyszek: Issue #2993: Change: Increase vm.max_map_count value - fesco - Pagure.io - https://pagure.io/fesco/issue/2993
17:23:44 <nirik> I think we need more info and there wasn't much in the devel thread in the way of answers, so -1 from me for now...
17:23:53 <zbyszek> We have aleasto here
17:24:22 <music[m]> zbyszek: Thank you for keeping eyes on the big picture. Your dissent is valuable.
17:24:31 <aleasto> i've tracked down the source of the current value: https://github.com/torvalds/linux/blob/v2.6.12-rc2/include/linux/sched.h#L190
17:24:40 <aleasto> "This is a random (large) number"
17:25:07 * mhayden enjoys the descriptive comment provided
17:25:31 <music[m]> https://xkcd.com/221/
17:25:32 <zbyszek> That is true. But that's a very big step to 2147483642.
17:25:39 <decathorpe> I'd be interested in the reason for bumping the limit to 4 billion instead of some more "limited" raise to a few million
17:25:49 <nirik> yeah.
17:26:06 <zbyszek> And also, with the raised limit, what happens with the reproducer posted by Florian Weimer. Does the machine go down?
17:26:15 <decathorpe> the issues for games I saw referenced values as high as ~16 million, which is far from 4 billion
17:26:36 <aleasto> i haven't tried the reproducer
17:26:58 <music[m]> zbyszek: I would also like to know the answer to that for any proposed lower value.
17:27:07 <mhroncok> -1 to the proposal as is
17:27:20 <mhroncok> I have to leave now for a couple minutes, sorry, this was unexpected
17:27:48 <zbyszek> OK, so aleasto, can you do some more research and come back with an amended proposal and results of checks?
17:28:12 <aleasto> i think the research would have to sending an RFC to lkml
17:28:20 <aleasto> s/have to/have to be/
17:28:25 <aleasto> which sure, i can do
17:28:50 <zbyszek> No, research as in setting some values and trying to crash a system in one or two configurations.
17:29:41 <aleasto> ok
17:29:53 <zbyszek> We have done various changes to the system respond properly to memory overload. We have early-oom/oomd, and some resource separation, etc.
17:30:19 <zbyszek> We don't want to open an easy avenue of making the system crash or become nonresponsive.
17:30:25 <aleasto> i saw we also just changed the oomd kill threshold
17:31:00 <zbyszek> That's a different story: oomd is too agressive when we have zram, but no real swap. So we're effectively making it less likely to act.
17:31:12 <nirik> in the tests I think it was noted that oomd killer doesn't handle this case right?
17:31:17 <zbyszek> Yeah.
17:31:38 <aleasto> yea which sounds like a bug in oomd
17:31:46 <aleasto> i mean why should the map count matter
17:31:52 <aleasto> but yea i can try different values...
17:32:20 <aleasto> what i won't be able to try is running the affected steam games i don't own :p
17:32:49 <zbyszek> I think we can assume that if we raise it enough, they will run.
17:32:51 <sgallagh> Sadly, FESCo doesn't have the budget to buy you games for testing :)
17:33:02 <zbyszek> The question is how this affects non-game use.
17:33:23 <zbyszek> #action aleasto to try with different settings, check machine stability.
17:33:27 <zbyszek> OK?
17:33:55 <aleasto> i think the value is purely an implementation detail of vma
17:34:02 <aleasto> also based on the in-line comment
17:34:26 <zbyszek> It is also possible that the machine crashes with the current default too.
17:34:37 <zbyszek> Then we have a bigger problem.
17:34:45 <zbyszek> But somebody needs to check that.
17:35:03 <aleasto> ok
17:35:30 <zbyszek> Unless there's more comments, I'll move to the next topic.
17:35:52 <nirik> thanks aleasto!
17:36:00 <zbyszek> Yep, thanks aleasto.
17:36:01 <zbyszek> #topic Next week's chair
17:36:12 <zbyszek> Volunteers?
17:36:19 <zbyszek> A volunteer?
17:36:45 <sgallagh> I'll do it
17:36:49 <zbyszek> Thanks!
17:36:57 <zbyszek> #action sgallagh will chair the next meeting
17:37:01 <zbyszek> #topic Open Floor
17:37:48 <zbyszek> If nothing, let's wrap this up.
17:38:06 <zbyszek> Thanks everyone.
17:38:11 <zbyszek> #endmeeting