linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Minchan Kim <minchan@kernel.org>, <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<kernel-team@fb.com>
Subject: Re: [PATCH 3/3] dcache: account external names as indirectly reclaimable memory
Date: Tue, 17 Apr 2018 12:24:13 +0100	[thread overview]
Message-ID: <20180417112412.GB28901@castle.DHCP.thefacebook.com> (raw)
In-Reply-To: <20180416114144.GK17484@dhcp22.suse.cz>

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 worth it,
> > > > especially if we find more similar usages. I suspect they would be more
> > > > useful than the existing dma-kmalloc-X :)
> > > 
> > > I am still not sure why __GFP_RECLAIMABLE cannot be made work as
> > > expected and account slab pages as SLAB_RECLAIMABLE
> > 
> > Can you outline how this would work without separate caches?
> 
> I thought that the cache would only maintain two sets of slab pages
> depending on the allocation reuquests. I am pretty sure there will be
> other details to iron out and 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 be more reasonable. Is this worth exploring
> at least? I mean something like this should help with the fragmentation
> already AFAIU. Accounting would be just free on top.

IMO, this approach is much better than duplicating all kmalloc caches.
It's definitely has to be explored and discussed.

Thank you!

      parent reply	other threads:[~2018-04-17 11:24 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 13:37 [PATCH 0/3] indirectly reclaimable memory Roman Gushchin
2018-03-05 13:37 ` [PATCH 1/3] mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES Roman Gushchin
2018-04-11 13:16   ` Vlastimil Babka
2018-04-11 13:56     ` Roman Gushchin
2018-04-12  6:52       ` Vlastimil Babka
2018-04-12 11:52         ` Michal Hocko
2018-04-12 14:38           ` Roman Gushchin
2018-04-12 14:46             ` Michal Hocko
2018-04-12 14:57         ` Roman Gushchin
2018-04-13  6:59           ` Michal Hocko
2018-04-13 12:13           ` vinayak menon
2018-04-25  3:49             ` Vijayanand Jitta
2018-04-25 12:52               ` Roman Gushchin
2018-04-25 15:47                 ` Vlastimil Babka
2018-04-25 16:48                   ` Roman Gushchin
2018-04-25 17:02                     ` Vlastimil Babka
2018-04-25 17:23                       ` Roman Gushchin
2018-04-25 15:55             ` Matthew Wilcox
2018-04-25 16:59               ` Vlastimil Babka
2018-03-05 13:37 ` [PATCH 2/3] mm: add indirectly reclaimable memory to MemAvailable Roman Gushchin
2018-03-05 13:47   ` Roman Gushchin
2018-03-05 13:37 ` [PATCH 2/3] mm: treat indirectly reclaimable memory as available in MemAvailable Roman Gushchin
2018-03-05 13:37 ` [PATCH 3/3] dcache: account external names as indirectly reclaimable memory Roman Gushchin
2018-03-12 21:17   ` Al Viro
2018-03-12 22:36     ` Roman Gushchin
2018-03-13  0:45       ` Al Viro
2018-04-05 22:11         ` Andrew Morton
2018-04-06 10:32           ` Roman Gushchin
2018-04-13 13:35   ` Minchan Kim
2018-04-13 13:59     ` Michal Hocko
2018-04-13 14:20       ` Vlastimil Babka
2018-04-13 14:28         ` Michal Hocko
2018-04-13 14:37           ` Johannes Weiner
2018-04-16 11:41             ` Michal Hocko
2018-04-16 12:06               ` Vlastimil Babka
2018-04-16 12:27                 ` Michal Hocko
2018-04-16 19:57                   ` Vlastimil Babka
2018-04-17  6:44                     ` Michal Hocko
2018-04-16 13:09                 ` Matthew Wilcox
2018-04-17 11:24               ` Roman Gushchin [this message]

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=20180417112412.GB28901@castle.DHCP.thefacebook.com \
    --to=guro@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /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).