From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f198.google.com (mail-wj0-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id DE3516B0033 for ; Fri, 27 Jan 2017 08:12:21 -0500 (EST) Received: by mail-wj0-f198.google.com with SMTP id ez4so46649385wjd.2 for ; Fri, 27 Jan 2017 05:12:21 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id k20si2790359wmc.118.2017.01.27.05.12.19 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 27 Jan 2017 05:12:20 -0800 (PST) Date: Fri, 27 Jan 2017 14:12:18 +0100 From: Michal Hocko Subject: Re: [ATTEND] many topics Message-ID: <20170127131218.GH4143@dhcp22.suse.cz> References: <878tq5ff0i.fsf@notabene.neil.brown.name> <20170121131644.zupuk44p5jyzu5c5@thunk.org> <87ziijem9e.fsf@notabene.neil.brown.name> <20170123060544.GA12833@bombadil.infradead.org> <20170123170924.ubx2honzxe7g34on@thunk.org> <87mvehd0ze.fsf@notabene.neil.brown.name> <58357cf1-65fc-b637-de8e-6cf9c9d91882@suse.cz> <8760l2vibg.fsf@notabene.neil.brown.name> <20170126085639.GA6590@dhcp22.suse.cz> <87tw8ltt6n.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tw8ltt6n.fsf@notabene.neil.brown.name> Sender: owner-linux-mm@kvack.org List-ID: To: NeilBrown Cc: Vlastimil Babka , Theodore Ts'o , Matthew Wilcox , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org On Fri 27-01-17 08:20:00, NeilBrown wrote: > On Thu, Jan 26 2017, Michal Hocko wrote: > > > On Thu 26-01-17 10:19:31, NeilBrown wrote: > > > >> I think it would be better if we could discard the idea of "reclaimable" > >> and just stick with "movable" and "unmovable". Lots of things are not > >> movable at present, but could be made movable with relatively little > >> effort. Once the interfaces are in place to allow arbitrary kernel code > >> to find out when things should be moved, I suspect that a lot of > >> allocations could become movable. > > > > I believe we need both. There will be many objects which are hard to be > > movable yet they are reclaimable which can help to reduce the > > fragmentation longterm. > > Do we? Any "reclaimable" objects which are "busy", are really > "unmovable" objects, and so contribute to fragmentation. true and not much different from other reclaimable or movable objects. E.g. a pinned LRU page is also unmovable. > I've been thinking about inodes and dentries - which usually come up as > problematic objects in this context. > It would be quite complex to support moving arbitrary inodes or dentries > given the current design. But maybe we don't need to. > Suppose these objects were allocated as 'movable', but when the first > long-term reference was taken (i.e. the first non-movable reference), > they were first moved to the "non-movable" region? I am not familiar with the [di]cache enough to comment on how easy would be to move those objects around. But there were already suggestions that LRU pages would be migrated before a long term pins to not block migration. Anyway this sounds like a topic on its own. From the current discussion so far it really seems that it would be really hard to define sensible semantic for GFP_TEMPORARY with the current implementation so I will send a patch to simply drop this flag. If we want to have such a flag then we should start over with defining the semantic first and think this thing over properly. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org