[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201605130009.EAJ35441.JLtFVOHFOSOMQF@I-love.SAKURA.ne.jp>
Date: Fri, 13 May 2016 00:09:07 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: hillf.zj@...baba-inc.com, mhocko@...nel.org
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v5] mm: Add memory allocation watchdog kernel thread.
Hillf Danton wrote:
> > +struct memalloc_info {
> > + /*
> > + * 0: not doing __GFP_RECLAIM allocation.
> > + * 1: doing non-recursive __GFP_RECLAIM allocation.
> > + * 2: doing recursive __GFP_RECLAIM allocation.
> > + */
> > + u8 valid;
> > + /*
> > + * bit 0: Will be reported as OOM victim.
> > + * bit 1: Will be reported as dying task.
> > + * bit 2: Will be reported as stalling task.
> > + * bit 3: Will be reported as exiting task.
> > + * bit 7: Will be reported unconditionally.
> > + */
> > + u8 type;
> > + /* Index used for memalloc_in_flight[] counter. */
> > + u8 idx;
>
> u8 __pad; is also needed perhaps.
>
Since this structure is not marked as __packed, I think that
the compiler will automatically pad it.
> The numbers assigned to type may be replaced with texts,
> for instance,
> MEMALLOC_TYPE_VICTIM
> MEMALLOC_TYPE_DYING
> MEMALLOC_TYPE_STALLING
> MEMALLOC_TYPE_EXITING
> MEMALLOC_TYPE_REPORT
>
I can define them as bit shift numbers. Thanks.
Michal, this version eliminated overhead of walking the process list
when nothing is wrong. You are aware of the possibility of
debug_show_all_locks() failing to report the culprit, aren't you?
So, what are unacceptable major problems for you?
Powered by blists - more mailing lists