On Wed, Oct 18, 2023 at 1:22 AM Oliver Sang <oliver.sang@xxxxxxxxx> wrote: > > hi, Yosry Ahmed, hi, Shakeel Butt, > > On Thu, Oct 12, 2023 at 03:23:06PM -0700, Yosry Ahmed wrote: > > On Thu, Oct 12, 2023 at 2:39 PM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > > > > > On Thu, Oct 12, 2023 at 2:20 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > > [...] > > > > > > > > > > Yes this looks better. I think we should also ask intel perf and > > > > > phoronix folks to run their benchmarks as well (but no need to block > > > > > on them). > > > > > > > > Anything I need to do for this to happen? (I thought such testing is > > > > already done on linux-next) > > > > > > Just Cced the relevant folks. > > > > > > Michael, Oliver & Feng, if you have some time/resource available, > > > please do trigger your performance benchmarks on the following series > > > (but nothing urgent): > > > > > > https://lore.kernel.org/all/20231010032117.1577496-1-yosryahmed@xxxxxxxxxx/ > > > > Thanks for that. > > we (0day team) have already applied the patch-set as: > > c5f50d8b23c79 (linux-review/Yosry-Ahmed/mm-memcg-change-flush_next_time-to-flush_last_time/20231010-112257) mm: memcg: restore subtree stats flushing > ac8a48ba9e1ca mm: workingset: move the stats flush into workingset_test_recent() > 51d74c18a9c61 mm: memcg: make stats flushing threshold per-memcg > 130617edc1cd1 mm: memcg: move vmstats structs definition above flushing code > 26d0ee342efc6 mm: memcg: change flush_next_time to flush_last_time > 25478183883e6 Merge branch 'mm-nonmm-unstable' into mm-everything <---- the base our tool picked for the patch set > > they've already in our so-called hourly-kernel which under various function > and performance tests. > > our 0day test logic is if we found any regression by these hourly-kernels > comparing to base (e.g. milestone release), auto-bisect will be triggnered. > then we only report when we capture a first bad commit for a regression. > > based on this, if you don't receive any report in following 2-3 weeks, you > could think 0day cannot capture any regression from your patch-set. > > *However*, please be aware that 0day is not a traditional CI system, and also > due to resource constraints, we cannot guaratee coverage, we cannot tigger > specific tests for your patchset, either. > (sorry if this is not your expectation) > Thanks for taking a look and clarifying this, much appreciated. Fingers crossed for not getting any reports :)
