> No, it's not. This is controlled higher in shrink_slab() by this:
>
> max_pass = do_shrinker_shrink(shrinker, shrink, 0);
> if (max_pass <= 0)
> continue;
>
Yes, but the later calls will still not handle other negative values as
failures, and there is a chance that
No, it's not. This is controlled higher in shrink_slab() by this:
max_pass = do_shrinker_shrink(shrinker, shrink, 0);
if (max_pass = 0)
continue;
Yes, but the later calls will still not handle other negative values as
failures, and there is a chance that more
On 22:00 Tue 16 Apr , David Rientjes wrote:
> On Tue, 16 Apr 2013, Oskar Andero wrote:
>
> > > > The comment in shrinker.h is misleading, not the source code.
> > > > do_shrinker_shrink() will fail for anything negative and 0.
> > >
> > > The comment is correct. The only acceptable negative
On 22:00 Tue 16 Apr , David Rientjes wrote:
On Tue, 16 Apr 2013, Oskar Andero wrote:
The comment in shrinker.h is misleading, not the source code.
do_shrinker_shrink() will fail for anything negative and 0.
The comment is correct. The only acceptable negative return is -1.
On Tue, 16 Apr 2013, Oskar Andero wrote:
> > > The comment in shrinker.h is misleading, not the source code.
> > > do_shrinker_shrink() will fail for anything negative and 0.
> >
> > The comment is correct. The only acceptable negative return is -1.
> > Look at the second time
On 08:19 Tue 16 Apr , Dan Carpenter wrote:
> On Mon, Apr 15, 2013 at 04:11:18PM -0700, David Rientjes wrote:
> > On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
> >
> > > > The positive numbers are used to return information on the remaining
> > > > cache size (again, see the comment I pasted
On Mon, Apr 15, 2013 at 04:11:18PM -0700, David Rientjes wrote:
> On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
>
> > > The positive numbers are used to return information on the remaining
> > > cache size (again, see the comment I pasted above). We could use
> > > -EBUSY, but we'd have to
On Mon, Apr 15, 2013 at 04:11:18PM -0700, David Rientjes wrote:
On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
The positive numbers are used to return information on the remaining
cache size (again, see the comment I pasted above). We could use
-EBUSY, but we'd have to change vmscan.c,
On 08:19 Tue 16 Apr , Dan Carpenter wrote:
On Mon, Apr 15, 2013 at 04:11:18PM -0700, David Rientjes wrote:
On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
The positive numbers are used to return information on the remaining
cache size (again, see the comment I pasted above). We
On Tue, 16 Apr 2013, Oskar Andero wrote:
The comment in shrinker.h is misleading, not the source code.
do_shrinker_shrink() will fail for anything negative and 0.
The comment is correct. The only acceptable negative return is -1.
Look at the second time do_shrinker_shrink() is
On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
> > The positive numbers are used to return information on the remaining
> > cache size (again, see the comment I pasted above). We could use
> > -EBUSY, but we'd have to change vmscan.c, which checks specifically
> > for -1. I can't see a technical
On Mon, Apr 15, 2013 at 08:28:07PM +0200, Dolkow, Snild wrote:
> >> > >From the comments in shrinker.h:
> >> > "It should return the number of objects which remain in the cache.
> >> > If it returns -1, it means it cannot do any scanning at this time
> >> > (eg. there is a risk of deadlock). The
>> > >From the comments in shrinker.h:
>> > "It should return the number of objects which remain in the cache.
>> > If it returns -1, it means it cannot do any scanning at this time
>> > (eg. there is a risk of deadlock). The callback must not return -1
>> > if nr_to_scan is zero."
>>
>
>IMO one
On 16:13 Mon 15 Apr , Dan Carpenter wrote:
> On Mon, Apr 15, 2013 at 03:38:08PM +0200, Dolkow, Snild wrote:
> > >Where is lowmem_shrink called from? I only see shrink called from the
> > >bcache sysfs handler __bch_cache_set(). The return value isn't checked
> > >there.
> > >
> > >Up to now
On Mon, Apr 15, 2013 at 03:38:08PM +0200, Dolkow, Snild wrote:
> >Where is lowmem_shrink called from? I only see shrink called from the
> >bcache sysfs handler __bch_cache_set(). The return value isn't checked
> >there.
> >
> >Up to now this function has only returns positive numbers.
> >
>
>Where is lowmem_shrink called from? I only see shrink called from the
>bcache sysfs handler __bch_cache_set(). The return value isn't checked
>there.
>
>Up to now this function has only returns positive numbers.
>
>There isn't a place which check LMK_BUSY so maybe it's best to just
>return
On Mon, Apr 15, 2013 at 03:03:29PM +0200, Oskar Andero wrote:
> From: Snild Dolkow
>
> Running multiple instances of LMK is not useful since it will try to
> kill the same process.
>
> This patch adds a spinlock to prevent multiple instances of the LMK
> running at the same time. Uses
On Mon, Apr 15, 2013 at 03:03:29PM +0200, Oskar Andero wrote:
From: Snild Dolkow snild.dol...@sonymobile.com
Running multiple instances of LMK is not useful since it will try to
kill the same process.
This patch adds a spinlock to prevent multiple instances of the LMK
running at the same
Where is lowmem_shrink called from? I only see shrink called from the
bcache sysfs handler __bch_cache_set(). The return value isn't checked
there.
Up to now this function has only returns positive numbers.
There isn't a place which check LMK_BUSY so maybe it's best to just
return zero?
Hey
On Mon, Apr 15, 2013 at 03:38:08PM +0200, Dolkow, Snild wrote:
Where is lowmem_shrink called from? I only see shrink called from the
bcache sysfs handler __bch_cache_set(). The return value isn't checked
there.
Up to now this function has only returns positive numbers.
There isn't a
On 16:13 Mon 15 Apr , Dan Carpenter wrote:
On Mon, Apr 15, 2013 at 03:38:08PM +0200, Dolkow, Snild wrote:
Where is lowmem_shrink called from? I only see shrink called from the
bcache sysfs handler __bch_cache_set(). The return value isn't checked
there.
Up to now this function
From the comments in shrinker.h:
It should return the number of objects which remain in the cache.
If it returns -1, it means it cannot do any scanning at this time
(eg. there is a risk of deadlock). The callback must not return -1
if nr_to_scan is zero.
IMO one should use the errno.h
On Mon, Apr 15, 2013 at 08:28:07PM +0200, Dolkow, Snild wrote:
From the comments in shrinker.h:
It should return the number of objects which remain in the cache.
If it returns -1, it means it cannot do any scanning at this time
(eg. there is a risk of deadlock). The callback must not
On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
The positive numbers are used to return information on the remaining
cache size (again, see the comment I pasted above). We could use
-EBUSY, but we'd have to change vmscan.c, which checks specifically
for -1. I can't see a technical reason
24 matches
Mail list logo
