Balbir Singh <bsingharora@xxxxxxxxx> 于2021年12月7日周二 13:16写道： > > On Sun, Dec 05, 2021 at 07:08:02PM +0800, yong w wrote: > > Balbir Singh <bsingharora@xxxxxxxxx> 于2021年12月5日周日 16:17写道： > > > > > > On Sat, Dec 04, 2021 at 04:09:55AM -0800, yongw.pur@xxxxxxxxx wrote: > > > > From: wangyong <wang.yong12@xxxxxxxxxx> > > > > > > > > Delay accounting does not track the delay of memory compact. > > > > When there is not enough free memory, tasks can spend > > > > a amount of their time waiting for compact. > > > > > > > > To get the impact of tasks in direct memory compact, measure > > > > the delay when allocating memory through memory compact. > > > > > > > > > > Should we call this DIRECT_COMPACT and through documentation > > > or name change imply that this won't work for kcompactd the > > > kernel thread - based on my reading of the patches. > > > > > Using DIRECT_COMPACT is a little redundant，because the > > delayacct stats of delay accounting is specific to tasks, it has > > nothing to do with kcompactd, which is similar to the RECLAIM field. > > > > What would we expect when we call delayacct -p <pidof kcompactd> > to be output? If the slow path of memory allocation is invoked in the kcompacd process, there may be delays being recorded. > Don't feel to strongly, but it can be confusing that kcompactd > has spent no time in compact'ing? Not that delayacct is used for > kernel threads, but I am not sure if that use case exists today. Yes, delayacct does not restrict the process of obtaining information， but kcompactd is used for compaction, the compact delay of kcompatd is not actually a delay.Maybe it can be added to the document later to make it clearer. Thanks for your reply!
