linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: <jiang.biao2@zte.com.cn>
To: minchan@kernel.org
Cc: akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org,
	hillf.zj@alibaba-inc.com, ying.huang@intel.com,
	linux-mm@kvack.org, mgorman@techsingularity.net,
	linux-kernel@vger.kernel.org, zhong.weidong@zte.com.cn
Subject: Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.
Date: Mon, 27 Nov 2017 15:26:54 +0800 (CST)	[thread overview]
Message-ID: <201711271526547083632@zte.com.cn> (raw)
In-Reply-To: <20171127063846.GA27768@bbox>


[-- Attachment #1.1: Type: text/plain, Size: 1680 bytes --]

On Mon, Nov 27, 2017 at 02:27:20PM +0800, jiang.biao2@zte.com.cn wrote:> > I agree with your concern.  How about we take another way by
> > adding some warning in such case? such as,
> >         freeable = shrinker->count_objects(shrinker, shrinkctl);
> > +       if (unlikely(freeable < 0)) {
> > +               pr_err("shrink_slab: %pF negative objects returned. freeable=%ld\n",
> > +                       shrinker->scan_objects, freeable);
> > +               freeable = 0;  //maybe not needed?
> > +       }
> >         if (freeable == 0)
> >                 return 0;
> > In this way, we would not break the API, but could alert user exception
> > with message, and make it more robust in such case.
>
> True but it would be a problem robust vs. effectivess tradeoff.
> Think about that everyone want to make thier code robust.
> It means they start to dump lots of defensive code so code start
> to look like complicated as well as binary bloating.
> So, whenever we add some more, we should think how effective
> the code I am putting?
> 
> In this case, I'm skeptical, Sorry. But others might have different
> opinions. :)

With all due respect. I still think the robustness is more important than 
effectiveness in this case. :)
First, the minus value could break all the following procedure in 
do_shrink_slab which may lead to long time looping on 
*tight on memory* situations.
Second, there is *unlikely* macro to minimize the cost.
Third, there is already similar procedure for *total_scan < 0*.
Last, it did happen in my scenario and maybe happen in other 
unexpected situations.

Just my personal option, thanks a lot for you reply and explanation. :)

Regards,

  reply	other threads:[~2017-11-27  7:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27  1:37 [PATCH] mm/vmscan: make do_shrink_slab more robust Jiang Biao
2017-11-27  2:39 ` Minchan Kim
2017-11-27  4:46   ` jiang.biao2
2017-11-27  5:16     ` Minchan Kim
2017-11-27  6:27       ` jiang.biao2
2017-11-27  6:38         ` Minchan Kim
2017-11-27  7:26           ` jiang.biao2 [this message]
2017-11-27  8:27             ` Michal Hocko
2017-11-27  8:41               ` jiang.biao2

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201711271526547083632@zte.com.cn \
    --to=jiang.biao2@zte.com.cn \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=ying.huang@intel.com \
    --cc=zhong.weidong@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).