On Mon, Apr 16, 2018 at 01:41:44PM +0200, Michal Hocko wrote:
> On Fri 13-04-18 10:37:16, Johannes Weiner wrote:
> > On Fri, Apr 13, 2018 at 04:28:21PM +0200, Michal Hocko wrote:
> > > On Fri 13-04-18 16:20:00, Vlastimil Babka wrote:
> > > > We would need kmalloc-reclaimable-X variants. It could be
[the head of the thread is
http://lkml.kernel.org/r/08524819-14ef-81d0-fa90-d7af13c6b...@suse.cz]
On Mon 16-04-18 21:57:50, Vlastimil Babka wrote:
> On 04/16/2018 02:27 PM, Michal Hocko wrote:
> > On Mon 16-04-18 14:06:21, Vlastimil Babka wrote:
> >>
> >> For example the percpu (and other) array
On 04/16/2018 02:27 PM, Michal Hocko wrote:
> On Mon 16-04-18 14:06:21, Vlastimil Babka wrote:
>>
>> For example the percpu (and other) array caches...
>>
>>> maybe it will turn out that such a large
>>> portion of the chache would need to duplicate the state that a
>>> completely new cache would b
On Mon, Apr 16, 2018 at 02:06:21PM +0200, Vlastimil Babka wrote:
> On 04/16/2018 01:41 PM, Michal Hocko wrote:
> > On Fri 13-04-18 10:37:16, Johannes Weiner wrote:
> >> On Fri, Apr 13, 2018 at 04:28:21PM +0200, Michal Hocko wrote:
> >>> On Fri 13-04-18 16:20:00, Vlastimil Babka wrote:
> We wou
On Mon 16-04-18 14:06:21, Vlastimil Babka wrote:
> On 04/16/2018 01:41 PM, Michal Hocko wrote:
> > On Fri 13-04-18 10:37:16, Johannes Weiner wrote:
> >> On Fri, Apr 13, 2018 at 04:28:21PM +0200, Michal Hocko wrote:
> >>> On Fri 13-04-18 16:20:00, Vlastimil Babka wrote:
> We would need kmalloc-
On 04/16/2018 01:41 PM, Michal Hocko wrote:
> On Fri 13-04-18 10:37:16, Johannes Weiner wrote:
>> On Fri, Apr 13, 2018 at 04:28:21PM +0200, Michal Hocko wrote:
>>> On Fri 13-04-18 16:20:00, Vlastimil Babka wrote:
We would need kmalloc-reclaimable-X variants. It could be worth it,
especial
On Fri 13-04-18 10:37:16, Johannes Weiner wrote:
> On Fri, Apr 13, 2018 at 04:28:21PM +0200, Michal Hocko wrote:
> > On Fri 13-04-18 16:20:00, Vlastimil Babka wrote:
> > > We would need kmalloc-reclaimable-X variants. It could be worth it,
> > > especially if we find more similar usages. I suspect
On Fri, Apr 13, 2018 at 04:28:21PM +0200, Michal Hocko wrote:
> On Fri 13-04-18 16:20:00, Vlastimil Babka wrote:
> > We would need kmalloc-reclaimable-X variants. It could be worth it,
> > especially if we find more similar usages. I suspect they would be more
> > useful than the existing dma-kmall
On Fri 13-04-18 16:20:00, Vlastimil Babka wrote:
> On 04/13/2018 03:59 PM, Michal Hocko wrote:
> > On Fri 13-04-18 22:35:19, Minchan Kim wrote:
> >> On Mon, Mar 05, 2018 at 01:37:43PM +, Roman Gushchin wrote:
> > [...]
> >>> @@ -1614,9 +1623,11 @@ struct dentry *__d_alloc(struct super_block *sb
On 04/13/2018 03:59 PM, Michal Hocko wrote:
> On Fri 13-04-18 22:35:19, Minchan Kim wrote:
>> On Mon, Mar 05, 2018 at 01:37:43PM +, Roman Gushchin wrote:
> [...]
>>> @@ -1614,9 +1623,11 @@ struct dentry *__d_alloc(struct super_block *sb,
>>> const struct qstr *name)
>>> name = &sla
On Fri 13-04-18 22:35:19, Minchan Kim wrote:
> On Mon, Mar 05, 2018 at 01:37:43PM +, Roman Gushchin wrote:
[...]
> > @@ -1614,9 +1623,11 @@ struct dentry *__d_alloc(struct super_block *sb,
> > const struct qstr *name)
> > name = &slash_name;
> > dname = dentry->d_iname;
On Mon, Mar 05, 2018 at 01:37:43PM +, Roman Gushchin wrote:
> I was reported about suspicious growth of unreclaimable slabs
> on some machines. I've found that it happens on machines
> with low memory pressure, and these unreclaimable slabs
> are external names attached to dentries.
>
> Extern
On Thu, Apr 05, 2018 at 03:11:23PM -0700, Andrew Morton wrote:
> On Tue, 13 Mar 2018 00:45:32 + Al Viro wrote:
>
> > On Mon, Mar 12, 2018 at 10:36:38PM +, Roman Gushchin wrote:
> >
> > > Ah, I see...
> > >
> > > I think, it's better to account them when we're actually freeing,
> > > oth
On Tue, 13 Mar 2018 00:45:32 + Al Viro wrote:
> On Mon, Mar 12, 2018 at 10:36:38PM +, Roman Gushchin wrote:
>
> > Ah, I see...
> >
> > I think, it's better to account them when we're actually freeing,
> > otherwise we will have strange path:
> > (indirectly) reclaimable -> unreclaimable
On Mon, Mar 12, 2018 at 10:36:38PM +, Roman Gushchin wrote:
> Ah, I see...
>
> I think, it's better to account them when we're actually freeing,
> otherwise we will have strange path:
> (indirectly) reclaimable -> unreclaimable -> free
>
> Do you agree?
> +static void __d_free_external_name
On Mon, Mar 12, 2018 at 09:17:42PM +, Al Viro wrote:
> On Mon, Mar 05, 2018 at 01:37:43PM +, Roman Gushchin wrote:
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 5c7df1df81ff..a0312d73f575 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -273,8 +273,16 @@ static void __d_free
On Mon, Mar 05, 2018 at 01:37:43PM +, Roman Gushchin wrote:
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 5c7df1df81ff..a0312d73f575 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -273,8 +273,16 @@ static void __d_free(struct rcu_head *head)
> static void __d_free_external(struct rcu_h
17 matches
Mail list logo
