Michal Hocko wrote:
> > Does "that comment" refer to
> >
> > Elaborating the comment: the reason for the high wmark is to reduce
> > the likelihood of livelocks and be sure to invoke the OOM killer, if
> > we're still under pressure and reclaim just failed. The high wmark is
> > used to
Michal Hocko wrote:
> > Does "that comment" refer to
> >
> > Elaborating the comment: the reason for the high wmark is to reduce
> > the likelihood of livelocks and be sure to invoke the OOM killer, if
> > we're still under pressure and reclaim just failed. The high wmark is
> > used to
On Wed 01-11-17 23:38:49, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Wed 01-11-17 20:58:50, Tetsuo Handa wrote:
> > > > > But doing ALLOC_OOM for last second allocation attempt from
> > > > > out_of_memory() involve
> > > > > duplicating code (e.g. rebuilding zone list).
> > > >
> > > >
On Wed 01-11-17 23:38:49, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Wed 01-11-17 20:58:50, Tetsuo Handa wrote:
> > > > > But doing ALLOC_OOM for last second allocation attempt from
> > > > > out_of_memory() involve
> > > > > duplicating code (e.g. rebuilding zone list).
> > > >
> > > >
Michal Hocko wrote:
> On Wed 01-11-17 20:58:50, Tetsuo Handa wrote:
> > > > But doing ALLOC_OOM for last second allocation attempt from
> > > > out_of_memory() involve
> > > > duplicating code (e.g. rebuilding zone list).
> > >
> > > Why would you do it? Do not blindly copy and paste code
Michal Hocko wrote:
> On Wed 01-11-17 20:58:50, Tetsuo Handa wrote:
> > > > But doing ALLOC_OOM for last second allocation attempt from
> > > > out_of_memory() involve
> > > > duplicating code (e.g. rebuilding zone list).
> > >
> > > Why would you do it? Do not blindly copy and paste code
On Wed 01-11-17 20:58:50, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 22:51:49, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > > > > Michal Hocko wrote:
> > > > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > >
On Wed 01-11-17 20:58:50, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 22:51:49, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > > > > Michal Hocko wrote:
> > > > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > >
Michal Hocko wrote:
> On Tue 31-10-17 22:51:49, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > > > Michal Hocko wrote:
> > > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > > > While both have some merit, the first reason is mostly
Michal Hocko wrote:
> On Tue 31-10-17 22:51:49, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > > > Michal Hocko wrote:
> > > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > > > While both have some merit, the first reason is mostly
On Tue 31-10-17 22:51:49, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > > While both have some merit, the first reason is mostly historical
> > > > > > because we
On Tue 31-10-17 22:51:49, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > > While both have some merit, the first reason is mostly historical
> > > > > > because we
Michal Hocko wrote:
> On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > While both have some merit, the first reason is mostly historical
> > > > > because we have the explicit locking now and it is really unlikely
Michal Hocko wrote:
> On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > > While both have some merit, the first reason is mostly historical
> > > > > because we have the explicit locking now and it is really unlikely
On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > While both have some merit, the first reason is mostly historical
> > > > because we have the explicit locking now and it is really unlikely that
> > > > the memory would
On Tue 31-10-17 22:13:05, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > > While both have some merit, the first reason is mostly historical
> > > > because we have the explicit locking now and it is really unlikely that
> > > > the memory would
Michal Hocko wrote:
> On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > While both have some merit, the first reason is mostly historical
> > > because we have the explicit locking now and it is really unlikely that
> > > the memory would be available right after we have given up trying.
> > >
Michal Hocko wrote:
> On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> > > While both have some merit, the first reason is mostly historical
> > > because we have the explicit locking now and it is really unlikely that
> > > the memory would be available right after we have given up trying.
> > >
On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 19:40:09, Tetsuo Handa wrote:
> > > The reason I used __alloc_pages_slowpath() in
> > > alloc_pages_before_oomkill() is
> > > to avoid duplicating code (such as checking for ALLOC_OOM and rebuilding
> > >
On Tue 31-10-17 21:42:23, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 31-10-17 19:40:09, Tetsuo Handa wrote:
> > > The reason I used __alloc_pages_slowpath() in
> > > alloc_pages_before_oomkill() is
> > > to avoid duplicating code (such as checking for ALLOC_OOM and rebuilding
> > >
Michal Hocko wrote:
> On Tue 31-10-17 19:40:09, Tetsuo Handa wrote:
> > The reason I used __alloc_pages_slowpath() in alloc_pages_before_oomkill()
> > is
> > to avoid duplicating code (such as checking for ALLOC_OOM and rebuilding
> > zone
> > list) which needs to be maintained in sync with
Michal Hocko wrote:
> On Tue 31-10-17 19:40:09, Tetsuo Handa wrote:
> > The reason I used __alloc_pages_slowpath() in alloc_pages_before_oomkill()
> > is
> > to avoid duplicating code (such as checking for ALLOC_OOM and rebuilding
> > zone
> > list) which needs to be maintained in sync with
On Tue 31-10-17 19:40:09, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > +struct page *alloc_pages_before_oomkill(struct oom_control *oc)
> > > +{
> > > + /*
> > > + * Make sure that this allocation attempt shall not depend on
> > > + * __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation, for the
On Tue 31-10-17 19:40:09, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > +struct page *alloc_pages_before_oomkill(struct oom_control *oc)
> > > +{
> > > + /*
> > > + * Make sure that this allocation attempt shall not depend on
> > > + * __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation, for the
Michal Hocko wrote:
> > +struct page *alloc_pages_before_oomkill(struct oom_control *oc)
> > +{
> > + /*
> > +* Make sure that this allocation attempt shall not depend on
> > +* __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation, for the caller is
> > +* already holding oom_lock.
> >
Michal Hocko wrote:
> > +struct page *alloc_pages_before_oomkill(struct oom_control *oc)
> > +{
> > + /*
> > +* Make sure that this allocation attempt shall not depend on
> > +* __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation, for the caller is
> > +* already holding oom_lock.
> >
On Sat 28-10-17 17:07:09, Tetsuo Handa wrote:
> This patch splits last second allocation attempt into two locations, once
> before selecting an OOM victim and again after selecting an OOM victim,
> and uses normal watermark for last second allocation attempts.
Why do we need both?
> As of
On Sat 28-10-17 17:07:09, Tetsuo Handa wrote:
> This patch splits last second allocation attempt into two locations, once
> before selecting an OOM victim and again after selecting an OOM victim,
> and uses normal watermark for last second allocation attempts.
Why do we need both?
> As of
28 matches
Mail list logo
