RE: [PATCH v4] vmscan: add trace events for lru_gen

>>>On Mon, Sep 25, 2023 at 10:20?PM Jaewon Kim wrote: As the legacy lru provides, the lru_gen needs some trace events for debugging. This commit introduces 2 trace events. trace_mm_vmscan_lru_gen_scan trace_mm_vmscan_lru_gen_evict Each event is simi

RE: [PATCH v4] vmscan: add trace events for lru_gen

>>On Mon, Sep 25, 2023 at 10:20?PM Jaewon Kim wrote: >>> >>> As the legacy lru provides, the lru_gen needs some trace events for >>> debugging. >>> >>> This commit introduces 2 trace events. >>> trace_mm_vmscan_lru_gen_scan >>> trace_mm_vmscan_lru_gen_evict >>> >>> Each event is similar to the

RE: [PATCH v4] vmscan: add trace events for lru_gen

>On Mon, Sep 25, 2023 at 10:20?PM Jaewon Kim wrote: >> >> As the legacy lru provides, the lru_gen needs some trace events for >> debugging. >> >> This commit introduces 2 trace events. >> trace_mm_vmscan_lru_gen_scan >> trace_mm_vmscan_lru_gen_evict >> >> Each event is similar to the following

RE: [PATCH v3] vmscan: add trace events for lru_gen

>Hello, > >On Sun, 24 Sep 2023 23:23:43 +0900 Jaewon Kim wrote: > >> As the legacy lru provides, the lru_gen needs some trace events for >> debugging. >> >> This commit introduces 2 trace events. >> trace_mm_vmscan_lru_gen_scan >> trace_mm_vmscan_lru_gen_evict >> >> Each event is similar to

RE: [PATCH v2] vmscan: add trace events for lru_gen

>On Thu, 21 Sep 2023 09:12:30 -0700 > > >"T.J. Mercier" wrote: >

RE: (2) [PATCH] vmscan: add trace events for lru_gen

>> Great. Thank you for your comment. >> >> For the putting the struct scan_control *sc inside the trace, >> I couldn't do that because struct scan_control is defined in mm/vmscan.c. >> I think I should not move it to a seperate header file. > >Well if you ever decide to do so, one thing to do is

RE:(2) [PATCH] vmscan: add trace events for lru_gen

>On Tue, 19 Sep 2023 11:52:16 +0900 >Jaewon Kim wrote: > >> /* >> * Now redefine the EM() and EMe() macros to map the enums to the strings >> diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h >> index d2123dd960d5..e8f9d0452e89 100644 >> --- a/include/trace/events/vmsca

RE: [PATCH v4] page_alloc: consider highatomic reserve in watermark fast

>On Sat 20-06-20 08:59:58, Jaewon Kim wrote: >[...] >> @@ -3502,19 +3525,12 @@ bool __zone_watermark_ok(struct zone *z, unsigned >> int order, unsigned long mark, >> const bool alloc_harder = (alloc_flags & (ALLOC_HARDER|ALLOC_OOM)); >> >> /* free_pages may go negative - that's

RE:(2) [PATCH v2] page_alloc: consider highatomic reserve in wmartermark fast

>On 6/14/20 1:17 AM, Baoquan He wrote: >> On 06/13/20 at 10:08pm, Jaewon Kim wrote: >> ... >>> > > This is an example of ALLOC_HARDER allocation failure. >>> > > >>> > > <4>[ 6207.637280] [3: Binder:9343_3:22875] Binder:9343_3: page >>> > > allocation failure: order:0, mode:0x480020(GFP_ATOMIC),

RE: [patch] extcon: use correct size

Hi, Dan 02/05/2016 04:53 AM에 Dan Carpenter wrote: > > On Thu, Feb 04, 2016 at 01:47:41PM +0100, walter harms wrote: > > > > > > Am 04.02.2016 12:36, schrieb Dan Carpenter: > > > The info->status[] array has 3 elements. We are using size > > > MAX77843_MUIC_IRQ_NUM (16) instead of MAX77843_MUI