On Tue, Jul 18, 2017 at 05:28:14PM -0700, David Rientjes wrote:
> On Tue, 18 Jul 2017, Dave Chinner wrote:
>
> > > Thanks for looking into this, Dave!
> > >
> > > The number of GFP_NOFS allocations that build up the deferred counts can
> > > be unbounded, however, so this can become excessive,
On Tue, Jul 18, 2017 at 05:28:14PM -0700, David Rientjes wrote:
> On Tue, 18 Jul 2017, Dave Chinner wrote:
>
> > > Thanks for looking into this, Dave!
> > >
> > > The number of GFP_NOFS allocations that build up the deferred counts can
> > > be unbounded, however, so this can become excessive,
On Tue, 18 Jul 2017, Dave Chinner wrote:
> > Thanks for looking into this, Dave!
> >
> > The number of GFP_NOFS allocations that build up the deferred counts can
> > be unbounded, however, so this can become excessive, and the oom killer
> > will not kill any processes in this context.
On Tue, 18 Jul 2017, Dave Chinner wrote:
> > Thanks for looking into this, Dave!
> >
> > The number of GFP_NOFS allocations that build up the deferred counts can
> > be unbounded, however, so this can become excessive, and the oom killer
> > will not kill any processes in this context.
On Mon, Jul 17, 2017 at 01:37:35PM -0700, David Rientjes wrote:
> On Mon, 17 Jul 2017, Dave Chinner wrote:
>
> > > This is a side effect of super_cache_count() returning the appropriate
> > > count but super_cache_scan() refusing to do anything about it and
> > > immediately terminating with
On Mon, Jul 17, 2017 at 01:37:35PM -0700, David Rientjes wrote:
> On Mon, 17 Jul 2017, Dave Chinner wrote:
>
> > > This is a side effect of super_cache_count() returning the appropriate
> > > count but super_cache_scan() refusing to do anything about it and
> > > immediately terminating with
On Mon, 17 Jul 2017, Dave Chinner wrote:
> > This is a side effect of super_cache_count() returning the appropriate
> > count but super_cache_scan() refusing to do anything about it and
> > immediately terminating with SHRINK_STOP, mostly for GFP_NOFS allocations.
>
> Yup. Happens during
On Mon, 17 Jul 2017, Dave Chinner wrote:
> > This is a side effect of super_cache_count() returning the appropriate
> > count but super_cache_scan() refusing to do anything about it and
> > immediately terminating with SHRINK_STOP, mostly for GFP_NOFS allocations.
>
> Yup. Happens during
On Wed, Jul 12, 2017 at 01:42:35PM -0700, David Rientjes wrote:
> Hi Al and everyone,
>
> We're encountering an issue where the per-shrinker per-node deferred
> counts grow excessively large for the superblock shrinker. This appears
> to be long-standing behavior, so reaching out to you to see
On Wed, Jul 12, 2017 at 01:42:35PM -0700, David Rientjes wrote:
> Hi Al and everyone,
>
> We're encountering an issue where the per-shrinker per-node deferred
> counts grow excessively large for the superblock shrinker. This appears
> to be long-standing behavior, so reaching out to you to see
Hi Al and everyone,
We're encountering an issue where the per-shrinker per-node deferred
counts grow excessively large for the superblock shrinker. This appears
to be long-standing behavior, so reaching out to you to see if there's any
subtleties being overlooked since there is a reference to
Hi Al and everyone,
We're encountering an issue where the per-shrinker per-node deferred
counts grow excessively large for the superblock shrinker. This appears
to be long-standing behavior, so reaching out to you to see if there's any
subtleties being overlooked since there is a reference to
12 matches
Mail list logo
