Hi Vlastimil,
On Thu, Aug 24, 2017 at 10:00:49AM +0200, Vlastimil Babka wrote:
> On 08/24/2017 07:11 AM, Minchan Kim wrote:
> > Hello Chris,
> >
> > On Tue, Aug 22, 2017 at 02:53:24PM +0100, Chris Wilson wrote:
> >> Some shrinkers may only be able to free a bunch of objects at a time, and
> >> so
On Thu, 24 Aug 2017 10:00:49 +0200 Vlastimil Babka wrote:
> > Even if a
> > shrinker has a mistake, VM will have big trouble like infinite loop.
>
> We could fake 0 as 1 or something, at least.
If the shrinker returns sc->nr_scanned==0 then that's a buggy shrinker
- it should return SHRINK_STOP
On 08/24/2017 07:11 AM, Minchan Kim wrote:
> Hello Chris,
>
> On Tue, Aug 22, 2017 at 02:53:24PM +0100, Chris Wilson wrote:
>> Some shrinkers may only be able to free a bunch of objects at a time, and
>> so free more than the requested nr_to_scan in one pass.
Can such shrinkers reflect that in th
Hello Chris,
On Tue, Aug 22, 2017 at 02:53:24PM +0100, Chris Wilson wrote:
> Some shrinkers may only be able to free a bunch of objects at a time, and
> so free more than the requested nr_to_scan in one pass. Whilst other
> shrinkers may find themselves even unable to scan as many objects as
> the
Some shrinkers may only be able to free a bunch of objects at a time, and
so free more than the requested nr_to_scan in one pass. Whilst other
shrinkers may find themselves even unable to scan as many objects as
they counted, and so underreport. Account for the extra freed/scanned
objects against t
