lkml.org 
[lkml]   [2021]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 linux-next] delayacct: track delays from memory compact
On Sun, Dec 05, 2021 at 07:08:02PM +0800, yong w wrote:
> Balbir Singh <bsingharora@gmail.com> 于2021年12月5日周日 16:17写道:
> >
> > On Sat, Dec 04, 2021 at 04:09:55AM -0800, yongw.pur@gmail.com wrote:
> > > From: wangyong <wang.yong12@zte.com.cn>
> > >
> > > 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? Yes, I agree with your comment on the reclaim
field. 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.

<snip>

Balbir Singh.

\
 
 \ /
  Last update: 2021-12-07 06:17    [W:0.073 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site