+1 In our ecosystem (where memory gets progressively sized towards optimal via automatic history based right sizing ) we found this does not work well … and can cause incidents where nontrivial number of random pods start failing when there is memory pressure on nodes :(
But given this is flag guarded/opt-in, it will definitely benefits some class of apps/deployments. Regards, Mridul On Thu, Dec 18, 2025 at 12:53 AM Gengliang Wang <[email protected]> wrote: > +1 > > On Wed, Dec 17, 2025 at 10:16 AM bo yang <[email protected]> wrote: > >> +1 >> >> On Wed, Dec 17, 2025 at 9:33 AM karuppayya <[email protected]> >> wrote: >> >>> +1 (non-binding) >>> >>> On Wed, Dec 17, 2025 at 9:26 AM Cheng Pan <[email protected]> wrote: >>> >>>> +1 (non-binding) >>>> >>>> A very promising proposal. >>>> >>>> Thanks, >>>> Cheng Pan >>>> >>>> >>>> >>>> On Dec 18, 2025, at 00:52, Nan Zhu <[email protected]> wrote: >>>> >>>> thank you everyone and give my own +1 >>>> >>>> >>>> On Wed, Dec 17, 2025 at 8:43 AM Qiegang Long <[email protected]> wrote: >>>> >>>>> +1 non binding >>>>> >>>>> On Wed, Dec 17, 2025 at 11:38 AM Chao Sun <[email protected]> wrote: >>>>> >>>>>> Hi Spark devs, >>>>>> >>>>>> I would like to start a vote on the SPIP: Burst-aware memoryOverhead >>>>>> allocation algorithm for Spark@K8S >>>>>> >>>>>> Discussion thread: >>>>>> https://lists.apache.org/thread/85xob6ldnf9jpk7l8x64lknh4xff89sc >>>>>> SPIP: >>>>>> https://docs.google.com/document/d/1v5PQel1ygVayBFS8rdtzIH8l1el6H1TDjULD3EyBeIc >>>>>> JIRA: https://issues.apache.org/jira/browse/SPARK-54596 >>>>>> >>>>>> Please vote on the SPIP for the next 72 hours: >>>>>> >>>>>> [ ] +1: Accept the proposal as an official SPIP >>>>>> [ ] +0 >>>>>> [ ] -1: I don’t think this is a good idea because >>>>>> >>>>> >>>>
